Keith- Great questions. I'm the other author of the blog at thatsquality.com, and even I've been sort of kicking myself lately for not covering more than just the echo $form in the template. My intent was to really show how simply this stuff can be, but I've been regretting it more and more as of late!
Per your latest question, I'm may be a little confused. The configure method is not in the controller, it's in your form class, which is really part of the model. Validation is coupled with the model through each model-specific, form class in a few ways: 1) Symfony sets you up with basic validation via the type of your field when it auto-generates your form class 2) Further configuring of your validation is done in the form class (Fabien, am I right to essentially be calling this part of the model?), where validation is handled per each specific model field. So, as I see it, no validation should be in your controller, but rather in the new auto-generated form classes - where a form class is generated for each table in your schema. My opinion is based almost entirely from studying the source code, so Fabien, I'd love to have you clear up any mis-statements I may have just made. - Ryan On Jan 15, 10:58 am, Keith <[EMAIL PROTECTED]> wrote: > Hi Fabien, > > Thank you for clarifying the new form handling in a great blog post. > The view definitely has more power than I originally thought and I > better understand the new way form widgets are handled on the actual > view rather than just echo $form. > > My only remaining question is: how is data validation handled on the > model? Can the validator_schema be instantiated in the model? I see > from the helpful thatsquality.com tutorial series that they can be > instantiated within the configure() method, but that lives in the > controller. From an organizational standpoint, I'd like to keep > everything directly dealing with the model in the model, but am too > unfamiliar with the new system at this point to see how to make that > happen. > > I like how everything is decoupled from the framework so that it is re- > usable because it'll really help 3rd party vendors with their plugin > development by opening up the ways in which other kinds of data (XML > as you alluded to) can be handled by Symfony. > > - Keith > > On Jan 15, 9:24 am, Fabien POTENCIER <[EMAIL PROTECTED] > > project.com> wrote: > > Hi Keith, > > > Very interesting questions. As I really think the new form framework is > > the only one (that I know) that fully embraces the MVC pattern, I've > > just wrote an answer on my blog that try to explain the philosophy > > behind the design: > > >http://www.aide-de-camp.org/article/3/en/symfony-1-1-form-framework-a... > > > Fabien > > > -- > > Fabien Potencier > > Sensio CEO - symfony lead > > developerhttp://www.sensiolabs.com/http://www.symfony-project.com/ > > Sensio Labs > > Tél: +33 1 40 99 80 80 > > > Keith wrote: > > > I am a little confused about a few things in 1.1 with form handling > > > still. > > > > * Why is validation (something that in most MVC frameworks is handled > > > in the model) now handled in the controller? > > > > Doesn't this move the validation farther away from what it actually is > > > validating? > > > > * Why is form rendering also now in the controller? The view just > > > contains > > > > echo $form > > > > where the form should render. > > > > Isn't the form part of the view? It seems to me this new system mixes > > > both logic and presentation in how forms are rendered and validated. > > > > I feel like I'm missing something important in trying to understand > > > this because these changes seem very inconsistent with what the rest > > > of the MVC world is doing. At a time when other frameworks are > > > advocating skinny controllers and fat models, Symfony is taking things > > > away from the Model that should logically be handled there like > > > validation. > > > > Similarly, when other frameworks are moving towards having their > > > generators build code it's largely CSS driven, whereas the code here > > > is (by default) tables. This again seems like a step back given the > > > push for standards driven web design. > > > > I can certainly respect the power of the new methods that are > > > available, but I wonder why they are preferable given the stated roles > > > of the Model, View, & Controller and what direct benefits this gives > > > to designers who are separated from application development teams who > > > must now learn additional Symfony methods instead of being freed to > > > just be designers. > > > > I'm not trying to tear down what has obviously had a lot of thought > > > given the dramatic nature of the change. I'm just trying to understand > > > how it remains consistent with MVC principles. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
