I like both solutions! Thanks Ryan. I think these should both definitely be documented, they are both extremely useful in different circumstances.
Solution #1 seems like an excellent option for modifying individual widgets, and solution #2 would be useful for programatically modifying multiple widgets. For example, I could iterate over the $view array, pick out each date widget, and add a "ui-widget-datepicker" class to them so that I could initialize jQuery UI datepickers on each one with javascript in the view (the problem that made me ask this question in the first place). Or I could even modify widget attributes based on other existing attributes of the widget, like adding a special class to every widget that has the readonly or a required attribute. Thanks, Steve Viselli On Wed, May 11, 2011 at 5:35 AM, ryan weaver <[email protected]> wrote: > Hey guys- > > I hear you, and I think the new way it's handled is everything it was in > symfony1, but a little bit better since the customizations you *do* need to > make can be in the template. Below are two options that should work - I'm > curious which one everyone likes (or if there are others): Suppose you're in > a position where you can just echo the form, but you have one field - name - > that needs an extra class added on its widget. > > SOLUTION #1 > --------------------- > You can echo the whole form, but then *just* customize that one widget. > Reference is here (recently published): > http://symfony.com/doc/current/cookbook/form/twig_form_customization.html#how-to-customize-an-individual-field > > {% form_theme form _self %} > {% use 'TwigBundle:Form:div_layout.html.twig' %} > > {% block _product_name_widget %} > {% set attr = {'class': 'name_widget'} %} > {{ block('text_widget') }} > {% endblock %} > > {{ form_widget(form) }} > > SOLUTION #2 > --------------------- > > You should also be able to use your form class (e.g. ProductType) and > override the buildView(), which is what's actually preparing the FormView > object you pass to the template: > > class ProductType extends AbstractType > { > public function buildView(FormView $view, FormInterface $form) > { > parent::buildView($view, $form); > > $view['name']->setAttribute('class', 'name_widget'); > } > } > > Someone will need to try both of these, and I'd like to hear any feedback. > Perhaps one of these methods should be included in the documentation? > > Thanks! > > Ryan Weaver > US Office Head & Trainer - KnpLabs - Nashville, TN > http://www.knplabs.com <http://www.knplabs.com/en> > http://www.thatsquality.com > Twitter: @weaverryan > > > On Mon, May 9, 2011 at 12:15 PM, Richtermeister <[email protected]> wrote: > >> While I'm ok with the data-only approach, I really still fail to see >> this dogmatic insistence on manual form rendering. >> To me this is the opposite of DRY: fields in form, fields in template, >> makes form building a very repetitive task that adds little value >> except in cases where you need to style a specific field in a special >> way.. >> >> Personally I was very happy with echo $form and controlling the fields >> from inside the form. My template designers are also very happy with >> it, and I'm glad that ability is still with us. Seeing how often it's >> downplayed though I'm getting concerned it will eventually get the >> axe... >> >> Daniel >> >> >> >> On May 8, 2:30 pm, ericclemmons <[email protected]> wrote: >> > Then what's the best way of displaying these fields when the template >> > itself doesn't know which fields are being displayed (for example, >> > form fields are defined in a configuration or database)? >> > >> > On May 7, 7:07 pm, Steve VIselli <[email protected]> wrote: >> > >> > > Thanks for the replies Ryan and Vincent. That makes sense. >> > >> > > Steve >> > >> > > From: ryan weaver <[email protected]> >> > > Reply-To: <[email protected]> >> > > Date: Sat, 7 May 2011 15:33:44 -0500 >> > > To: <[email protected]> >> > > Subject: Re: [symfony-devs] Form Field HTML Attributes >> > >> > > Hi Steve! >> > >> > > Yes, as Vincent eluded to, this was a purposeful design decision. >> Unlike >> > > symfony1, the fields in Symfony2 have just one job: to move data back >> and >> > > forth between the domain object and what the user is >> seeing/submitting. So, >> > > the fields are 100% agnostic of actually being rendered. The advantage >> is >> > > that the markup for a field now lives inside a template instead of >> inside >> > > PHP classes as it did in symfony1. >> > >> > > So yes, it's a different mindset, but it should make your life easier >> in >> > > most cases. I understand that this means that you can't render the >> whole >> > > form with one line if you need custom attributes, but rendering with >> just >> > > one line is really meant for prototyping anyways. >> > >> > > I hope that helps clarify! >> > >> > > Ryan Weaver >> > > US Office Head & Trainer - KnpLabs - Nashville, TNhttp:// >> www.knplabs.com<http://www.knplabs.com/en>http://www.thatsquality.com >> > > Twitter: @weaverryan >> > >> > > On Sat, May 7, 2011 at 12:23 PM, Vincent Lechemin >> > >> > > <[email protected]> wrote: >> > >> > > > it's possible but while rendering in the view which is more logical >> > >> > > > -- >> > > > Vincent Lechemin >> > >> > > > -- >> > > > If you want to report a vulnerability issue on symfony, please send >> it to >> > > > security at symfony-project.com <http://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] >> > > > <mailto: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 athttp:// >> 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 >> > > -- > 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 > -- 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
