I wanted to one throw my support behind this idea because I agree with
it and I was just about to recommend the same thing in a ticket but
decided to do a search first.

Two, I wanted to know if anyone has a way currently of setting the
class attribute of the label tag with the the current 1.2.5-dev other
than rendering the that row individually.  I'm looking at the code and
looks like it is impossible because the ->renderLabel() called from
within renderRow() of sfFormField.class.php does not pass along
attributes at all.

Thanks for any help with this.

--
Stephen Ostrow <[email protected]>

On Feb 9, 3:43 am, Fabien Potencier <fabien.potenc...@symfony-
project.com> wrote:
> Can you create an enhancement ticket for each issue?
>
> Thanks,
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead developer
> sensiolabs.com | symfony-project.org | fabien.potencier.org
> Tél: +33 1 40 99 80 80
>
> avorobiev wrote:
> > 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/4c81...),
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to