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]> > >> 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]> > > 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
