+1 for dropping it To be honest we always dropped <?php echo $form ?> because it was not flexible enough. I only kept it in a few private projects were I never needed any designers or frontend devs.
2010/9/27 Fabien Potencier <[email protected]> > On 9/16/10 2:28 AM, Richtermeister wrote: > >> Hi all, >> >> just to chime in, I remember when the 1.1 form framework first came >> out there was some commotion over making it hard to customize forms. >> The usual reply at the time was that the form decorators should only >> be used during prototyping and when one needs manual control over >> layout, fields can just be rendered manually. >> Now, that actually went pretty well I thought, except when it comes to >> embedded forms. There, all fun is over and the pain begins, especially >> when you try one of those ajaxified "add more" embedded forms.. boy >> what a nightmare. Since I usually end up using a partial to render a >> form anyways (which again doesn't work with embedded forms), I'd >> welcome the idea of a native template renderer for forms very, very >> much! Just make sure it works for embedded forms! ;) >> > > One problem with the symfony1.1 form framework was also probably the fact > that many people wanted to keep the <?php echo $form ?> in their templates > as long as possible and be able to customize the layout the way they want > (which is of course not really possible -- or really difficult). > > I was thinking about dropping support for that shortcut in Symfony2. So, > the minimum code you will have to write to render a form would be something > like the following: > > <?php echo $f->errors() ?> > > <table> > <?php echo $f->row('gender') ?> > <?php echo $f->row('object') ?> > </table> > <?php echo $f->hidden() ?> > > <input type="submit" value="Update" /> > > I can see several benefits: > > * we can drop the need for different layout (table, div, ...); > * it is clearer than you have total control on the output; > * no more confusion about the real "value" of echo $form; > * rendering sub-forms is the developer responsibility (with calls to rows() > for instance -- more reflection is needed on this one). > > What do you think? > > Fabien > > > Daniel >> >> >> >> On Sep 15, 9:15 am, Dennis Benkert<[email protected]> >> wrote: >> >>> Well, I agree the agavi approach is not flawless, although forcing you >>>> to have valid html sounds more like a feature to me. >>>> >>> >>> Valid html code is absolutely a must have for me too. But the feeling I >>> have >>> about the Agavi approach is that is more like dictating you to have valid >>> html code (because otherwise the fpf won't work in any way). And we all >>> know >>> that one day or another you will have some invalid code in your project >>> (may >>> it be because of human errors, or crappy WYSIWYG editor, etc.). >>> >>> Also it feels a bit magical (like it felt back in symfony 1.0 days too) >>> when >>> your html code get's "enriched" by some "outside" code. imho this makes >>> debugging a harder task since you might get no feedback or your only >>> feedback will be that you don't see anything happen (like enriching your >>> html code). >>> >>> What might be good is to define your >>> >>> own "form templates" that can accept a bunch of fields and render them >>>> in your own way (wrapped with a<li> and god knows what you like). But >>>> that could be left entirely to the developer to build if he likes/needs >>>> it. >>>> >>> >>> I like this idea very much. >>> >>> - Dennis >>> >>> 2010/9/15 Jordi Boggiano<[email protected]> >>> >>> On 15.09.2010 14:59, Fabien Potencier wrote: >>>> >>>>> But this would also include that your html code has to be 100% valid >>>>>> all >>>>>> the time, doesn't it? In nearly every Agavi project we did we had hard >>>>>> times getting FPF (Form Population Filter) pleased because of html >>>>>> validation issues. Or aren't you talking about the FPF mechanism? >>>>>> >>>>> >>> Well, I agree the agavi approach is not flawless, although forcing you >>>> to have valid html sounds more like a feature to me. >>>> >>> >>> That is what we had in symfony 1... with all the problems. And this is >>>>> >>>> a totally different approach as you loose all the benefits of the form >>>> framework. >>>> >>> >>> All I'm hoping for is that the Symfony2 approach will be fast enough by >>>> default instead of privileging slowish syntax candy. I for one don't >>>> like form frameworks too much, and I think as Johannes said that most >>>> fields don't require a template. What might be good is to define your >>>> own "form templates" that can accept a bunch of fields and render them >>>> in your own way (wrapped with a<li> and god knows what you like). But >>>> that could be left entirely to the developer to build if he likes/needs >>>> it. >>>> >>> >>> Cheers >>>> >>> >>> -- >>>> Jordi Boggiano >>>> @seldaek ::http://seld.be/ >>>> >>> >>> -- >>>> If you want to report a vulnerability issue on symfony, please send it >>>> to >>>> security at symfony-project.com >>>> >>> >>> You received this message because you are subscribed to the Google >>>> Groups "symfony developers" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected]<symfony-devs%[email protected]> >>>> <symfony-devs%[email protected]<symfony-devs%[email protected]> >>>> > >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-devs?hl=en >>>> >>> >> > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" 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-devs?hl=en
