On 1/12/11 5:41 PM, Tom Boutell wrote:
I've discussed the default rendering of forms in Symfony 2 with our design guys and they have some input. I understand that simply rendering a form is frowned upon, but it is an aid to iterative development in which you are able to show the end user what the app will be like as soon as possible, get their feedback, improve, etc. before eventually "templating it all the way out" when the schema is ready to be cast in stone. So it makes a lot of sense for the markup to be written in such a way that it is easy to style it reasonably.Currently the markup generated by {{ form_field(form) }} is: <ul> <li>The CSRF token is invalid</li> </ul> <div> <label for="page_title">Title</label> <ul> <li>This value should not be blank</li> </ul> <input type="text" id="page_title" name="page[title]" value="" /> </div> <div> <label for="page_body">Body</label> <textarea id="page_body" name="page[body]"></textarea> </div> <input type="hidden" id="page__token" name="page[_token]" value="" />
The current markup is as easy as it can get. If you want to use it for something else than just getting the raw form rendered quickly, then you can just provide your own theme:
http://docs.symfony-reloaded.org/master/guides/forms/view.html#form-theming-twig-only Fabien
A few simple changes would make this significantly easier to style: * A class on the global errors list <ul class="sf_form_global_errors"> * Classes and ids on the div encapsulating each field <div class="sf_form_row sf_form_row_title" id="sf_form_row_page_title"> ...</div> The id should be self-explanatory, the first class is straightforward too. The id lets us target this exact row and the first class lets us target all form rows. The purpose of the second class, sf_form_row_title, is to allow all 'title' rows to be targeted via CSS when there are many forms on a page. It is considered a poor CSS practice to target everything with ids because of the "oops, now there are two of them" issue. * A span with a class around the widget itself <span class="sf-form-widget-date"><select year><select month><select day></span> The lack of wrappers around composite widgets has always been a barrier to styling them effectively. And the lack of a class for the widget means you can't effectively distinguish a checkbox from a plaintext input field with CSS due to the limitations of CSS. This change addresses both issues. * There should be no "naked" text nodes, for instance: <select year> <select month>** , **<select day> That comma there with the asterisks around it (produced by DateField in Symfony 2) is an un-targetable monster. It must be tamed (: The space between year and month is untargetable too although probably less of an issue in practice. Spans with meaningful class names would address this: <select year><span class="sf-year-month-separator"> </span><select month><span class="sf-month-day-separator">,</span><select day> * Classes on the errors list for a specific field <ul class="sf-form-errors"> With these simple additions it would be straightforward to do quite a bit with CSS and JS to style the default form rendering of Symfony. While I agree it makes sense to template most forms "all the way out" eventually, the above would make it much easier to prototype and iterate rapidly in response to client input, something Symfony has always supported well. I gather that Twig has a theming mechanism. I'm not sure to what extent that would make it easy for us to override form_field(form) ourselves in such a way that other bundles that don't go out of their way to change it would also be affected in our projects. If that is easy to do then that's already great news for us. But I think it is worth getting the default markup right for everyone. If folks are agreeable I could help to build these changes into the form component. I'm not just here to make work for people, honestly (: Thanks!
-- 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
