A question came across the mailing list today that provides an excellent opportunity to demonstrate the flexibility of the symfony 1.2 routing system.
Now that the release of Doctrine 1.1 right around the corner their has been a bit of noise about how users can use 1.1 instead of the default bundled 1.0.
Tutorial demonstrating how to setup a simple registration form for the sfDoctrineGuardPlugin.
Learn how you can execute complex queries and retrieve data using Doctrine in this Call the expert article.
In this tutorial we'll demonstrate how to extend the sfDoctrineGuardPlugin by adding a relationship to the sfGuardUser named Profile and integrating it in to the admin generator that comes with the plugin.
As announced in a previous post, symfony 1.2 is able to automatically save objects from deep nested forms. I gave a simple example in the announcement post, but some people asked me for a real project example. So here it is.
In this post we'll touch on a few different aspects of the symfony 1.2 release such as the new admin generators, form framework, and embedded forms with a tutorial that starts from a brand new project.
In the last part, we have moved some code to ProductForm. Today, we will enhance the actions even more by moving code to the View and by using some nice shortcuts provided by symfony for common situations.
In the last part, we have seen how to move code from the Controller to the Model. The principle is quite simple, you want thin controllers and fat models. Today, we will see how the new form framework can help us keep this clean separation of concerns.
Today, we will start by refactoring some actions from the product module. As symfony is modeled after the MVC design pattern, Vince was pretty confident that he did the separation of concerns pretty well. The Controller role is to get data from the Model and pass them to the View. Pretty simple, no?
- « Previous Page
- Next Page »