Also in the Form framework we need built-in:
- Required asterisk.
Today we can do it with overloading BaseForm and
sfWidgetFormSchemaFormatter (look at
http://groups.google.com/group/symfony-devs/browse_thread/thread/4c81264521f8bc60),
but it's not a clean way... If we have possibility to set asterisk as
a css class on the parent html-container, or as a class on the input|
select tag, that will be good!
- Field groups.
It often use in form decoration. If we have $form->render() function
why we can't use it for rendering form field groups?
In the form class we would set groups for example so:
$this->setWidgets(array(
'fieldGroupName1' => array(sfWigget classes),
'fieldGroupName2' => array(some other sfWigget classes),
and other sfWigget classes without field group
)
On Feb 5, 6:02 pm, Tom Boutell <[email protected]> wrote:
> Symfony 1.2 offers several levels of control over templates for forms.
> In practice, though, only two are useful:
>
> 1. echo $form
>
> Handy for quick and dirty testing and for situations where a pure and
> simple columnar layout enhanced a bit by CSS is acceptable. But all of
> the rows have to be styled in exactly the same way because there is no
> individual CSS access to them.
>
> 2. echo $form['fieldname']->renderLabel(),
> $form['fieldname']->render(), $form['fieldname']->renderErrors()
>
> Allows complete control over the HTML surrounding the row. But you
> pretty much have to do it for the entire form, or else do something
> ungainly like:
>
> while (($key, $dummyl) = each($form))
> {
> if ($key == 'foo')
> {
> special handling;
> }
> else
> {
> $key->renderRow();
> }
>
> }
>
> But what about $form->render(), which can accept a hash of widget
> names and HTML attributes for them? What about $form->renderRow(),
> which can also do that?
>
> The problem is that both of these methods only accept attributes for
> the widget control itself (the 'input' element, for instance). And
> this is not especially useful, because what we typically want to do is
> influence the layout of controls relative to one another. But we don't
> have any influence over the <tr> or <li> elements the input elements
> are embedded in. So we're stuck going all the way to the lowest level.
>
> I believe ->render() and ->renderRow() would be much more useful if
> they accepted attributes intended for the formatting element that
> contains the row, not just the attribute itself.
>
> Then you could write:
>
> $form->render(array('editors' => array('rowAttributes' =>
> array('class' => 'floating-column'))));
>
> ... To set a class on the <li> that encloses that particular row,
> allowing meaningful influence over the layout.
>
> Similar provisions for labelAttributes and errorsAttributes would also
> be helpful.
>
> (It would be nice if grandparent selectors worked in CSS, but they
> don't - you really can't look "up the tree" and change the layout of
> the element that your input element is contained in. So classes on the
> input element are not very useful in laying out a form.)
>
> --
> Tom Boutell
>
> www.punkave.comwww.boutell.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
-~----------~----~----~----~------~----~------~--~---
