Thanks Ryan for your series on forms, it was a great help since there is no other documentation for the 1.1 form stuff :)
Everything made sense, as its similar to another MVC pattern I've used, but one thing I couldn't do was get the form schema decorator outputting properly. I had a look through all the render calls as well and couldn't find it being referenced, so I'm not sure if I should open a issue or not.. Does anyone else suffer from this problem? Luckily I can just use the compat_10 :on in settings to get around the forms for now, but I see them as quite powerful, and would like to include them once it gets stable :) Cheers, Simon On Jan 16, 12:53 am, weaverryan <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
