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]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
