I should go to sleep ;) (Fixed typo and whatsoever)
Yuen-Chi Lian | www.yclian.com "I do not seek; I find." - Pablo Picasso On Tue, Sep 28, 2010 at 12:59 AM, Yuen-Chi Lian <[email protected]> wrote: > In our Sf1 project, we had some dilemmas and arguments on how we could do > this better, and ended up in our code, we have 3 approaches in our codebase: > > - The one suggested by Sf1's doc: <table/>, <form/>, echo $form, and > <input type="submit"/> in template. > - Fully object oriented, I extended the sfForm to support rendering the > HTML elements that are supposed to written in template. Yes, unit testable, > but it puts a limit on the form formatter choice and makes it really hard > to > further customize the form or its fields. > - Someone in my team was writing a "wizard" module that reuses widgets > from other form classes. She turned out using what you're proposing, in > Symfony 1 would be: $form['field']->render(). This turns out to be a > cleaner > solution. > > 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. > > The great thing about sfForm is the form processing part, the bind() and > validator's clean(). But the view part is really a nightmare to us. > > > > >> 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 >> >> -- 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
