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="" />
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!
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
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
