I think moving away from rendering form object-orientedly (including its structure, i.e. the form formatter stuff) is a better move as I highlighted earlier on my experience. - And it provides more flexibility for UI designers to customize the view.
However, I do agree that there're cases that developers want a do-it-all-for-me-in-one-subroutine solution. Yuen-Chi Lian | www.yclian.com "I do not seek; I find." - Pablo Picasso On Wed, Sep 29, 2010 at 12:48 AM, Richtermeister <[email protected]> wrote: > Hi all, > > one thing that always bothered me is that the form formatters are > nothing more than string-pattern storages that are merely being used > by the forms rendering methods. > I'd think it would be more intuitive and flexible to move all the > render logic into the formatter classes entirely and simply inject the > form, like so: $form = new FormFormatterTable(new CustomerForm()); > This would only be needed when handing a form to a template. > If this is too verbose, maybe a factory could be used: $form = > $container -> getFormFormatterService() -> format(new CustomerForm); > This way you can affect the formatter via configuration. > > The formatter baseclass would give access to the form fields, errors, > labels, etc, just as before, and simply add render methods.. in case > of List or Table formatters, renderRow methods would come to mind, but > in case of a FormFormatterTemplate renderer only a render method would > be needed which takes the template as argument.. > > Am I preaching to the choir (is that where you're already going with > this), or does this not make sense for reasons I don't yet see? > > Thanks, > Daniel > > > On Sep 27, 11:47 am, Gustavo Adrian <[email protected]> > wrote: > > I would prefer the verbose way. And I like the idea to keep row() and > > group() without a default template. > > > > I would like also to see the same example but with a embedded form and > > groups of fields ( I started to read Symfony 2 docs a few days ago :) ). > > Which would be the way to check if the field is a group or a embedded > form > > in that case, and how do you render them? And another question that comes > to > > mind.. the main form knows about errors on embedded forms? > > > > On Mon, Sep 27, 2010 at 3:33 PM, Pascal <[email protected]> wrote: > > > In this example how can i test if a field is in error ? > > > > > my proposal (looks very familiar ..) > > > > > <form action="#" method="post"> > > > > > <?php echo $f->getErrors() ?> > > > <table> > > > <tr class="<?php echo $form->hasError('first_name') ? > > > 'error' : '' ?>"> > > > <th> > > > <?php echo $form->getLabel('first_name') ?> > > > </th> > > > <td> > > > <?php echo $form->getError('first_name') ?> > > > <?php echo $form->getField('first_name') ?> > > > </td> > > > </tr> > > > > > // ... > > > > > But maybe it's too verbose, what do you guys think ? > > > > > [MA]Pascal > > > > > On Mon, Sep 27, 2010 at 18:25, Fabien Potencier < > > > [email protected]> wrote: > > > > >> On 9/27/10 6:59 PM, Yuen-Chi Lian wrote: > > > > >> If I can add an extra thing to what you suggested, I wish that > $f->row() > > >>> won't be rendering <li/> or <tr/>, as it may waste time for > developers > > >>> or designs to find a clean/dirty way to add custom objects into the > > >>> HTML, e.g. a light bulb, some fancy tips, etc. > > > > >> Yes, you are right, if we get rid of ->group() method (the one used by > > >> echo $form), we must also remove ->row() as it does not make sense > anymore. > > > > >> So, the minimum code would read as follows: > > > > >> <form action="#" method="post"> > > > > >> <?php echo $f->errors() ?> > > >> <table> > > >> <tr> > > >> <th> > > >> <?php echo $form->label('first_name') ?> > > >> </th> > > >> <td> > > >> <?php echo $form->error('first_name') ?> > > >> <?php echo $form->field('first_name') ?> > > >> </td> > > >> </tr> > > > > >> // ... > > > > >> </table> > > >> <?php echo $f->hidden() ?> > > >> <input type="submit" value="Update" /> > > >> </form> > > > > >> So, basically, we provide helpers to help render individual data > (errors, > > >> nice widgets, ...) but not the main structure of the form itself. > > > > >> Another possibility would be to keep the ->group() and ->row() methods > but > > >> without providing any "default" template. It means that you must write > those > > >> templates yourself if you want to use them. That way, you can > implement the > > >> display logic you want project-wise for form structures, and you will > be > > >> responsible for the "lack" of flexibility. > > > > >> Fabien > > > > >> -- > > >> 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 > > > > > -- > > > Pascal > > > > > -- > > > 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
