Hi Tom, Have you tried creating a custom generator class that provides an alternate widget class? I still think this is the best solution…
Thanks, Kris On Sep 1, 2010, at 5:27 PM, Tom Boutell wrote: > Marijn, I understand that "echo $form" is not supported as a way of > creating deployment-ready, properly styled Symfony sites. Fabien has > made that pretty clear - your design team is supposed to template out > forms if they want them to look good. I think there's a reasonable > middle ground somewhere but that's a completely separate discussion. > > Here I am talking about "echo $form['date']->render()". That is a > supported practice for well-styled Symfony sites, in fact it is the > lowest level the designer is supposed to be able to access according > to the relevant chapters of the Symfony books. This *is* "templating > out the form all the way." So it ought to be possible to get good > results with it from the standard widgets. The markup *inside* the > widget is not accessible to them (the front end designers), they > cannot fix it. And even if they could (perhaps by assuming that the id > format and name format will never change and writing their own form > elements, outputting all of their own attributes etc.), it would be a > considerable waste of time. Every time and date widget in a given site > will almost certainly have the same markup. > > We are currently overriding every single date and time widget via > configure() in every single Symfony 1.4 site. This takes a lot of time > and energy and it is worth questioning whether it is really true that > nothing can be done about it until we all rewrite everything for > Symfony 2.0. > > Unfortunately it's true that someone might be targeting span as a > (very lazy) alternative to a class name for something inside a form > row. As you point out they might feel safe doing so when they target > spans within a particular form. > > Don't forget, my original suggestion to have Base classes for the > widget was quite backwards compatible. I am hard pressed to imagine > why any Symfony code could care that a widget class now had an > additional parent in its tree of ancestor classes. I'm simply > responding to Jon and Fabien's suggestions that Base classes for > widgets are not an option, but that changing the markup might be > acceptable. We have lots of existing projects to support here too and > BC is a concern for us as well. Please don't assume the worst. > > Perhaps the best we can do is provide cleverness in > BaseForm::configure() that explicitly looks for the standard widgets > and replaces them with new widgets that receive the same options. It's > wasteful, but at least it's reusable. > > On Wed, Sep 1, 2010 at 8:03 PM, Marijn Huizendveld > <[email protected]> wrote: >> Dear Tom, >> As much as I agree with you that the current HTML is broken, this will >> create backwards incompatible changes. >> As much as I admire your effort to find the least obtrusive mark-up (on >> which choice I agree) I simply cannot come up with a reasonable explanation >> as to why we would want to create a possible backwards incompatible change >> like this... >> Although styling "naked" span elements is stupid I'm sure someone has a CSS >> rule like the following: >> form#my_admin_form #my_fieldset .sf_admin_form_row span >> { >> /*do something special here*/ >> } >> This is not generic styling but this will be effected by your changes in the >> time widget. >> It seems to me that the one and only reason you would like to get this >> change include is that you can simply keep on calling <?php echo $form; ?> >> in your template. >> As much as that utopia is desirable (and sometimes reasonable) it should >> never be considered the only viable option for creating forms. >> I'm sorry if I seem like a jerk but to me it seems you are trying to push a >> change through (again I agree for the need) that will fix a problem for you >> that has other solutions for it (override those default widgets in your own >> custom library, writing a more verbose template, creating a better time >> widget for the sfFormExtraPlugin). >> Again sorry for acting like a jerk who is putting his foot down, but could >> you explain my why you don't choose any of the less intrusive alternatives >> for other framework users? >> Kindest regards, >> Marijn >> On Sep 1, 2010, at 11:45 PM, Tom Boutell wrote: >> >> I would love to see that change made. Thank you for considering it. >> >> I just had a chat with John Benson, one of our lead front end guys. He >> wants this very much, but has his own backwards compatibility >> concerns. Changes to markup affect designers the way changes to PHP >> affect developers. >> >> Fortunately we have agreed on a safe way to do it. >> >> Right now we have this: >> >> <select>...</select> >> / >> <select>...</select> >> / >> <select>...</select> >> >> Two big problems: >> >> 1. There is no wrapper around the whole thing, thus no clean way to >> target the whole thing with CSS or JavaScript. I've seen imaginative >> and admirable hacks, but they are not clean and tend to target other >> stuff in unexpected ways. This kills attempts at full progressive >> enhancement. >> >> 2. The slashes (for dates) and colons (for times) have no wrapper, so >> they cannot be targeted. This kills attempts to style or alter the >> widgets for non-JS environments or otherwise improve them in ways less >> dramatic than full replacement by JS. >> >> Please help us out by giving the whole thing a class, and by giving >> the separators a class. Make sure those classes are namespaced to >> Symfony: >> >> // For date >> >> <span class="sf-date"> >> <select>...</select><span class="sf-separator">/</span> >> <select>...</select><span class="sf-separator">/</span> >> <select>...</select> >> </span> >> >> // For time >> >> <span class="sf-time"> >> <select>...</select><span class="sf-separator">:</span> >> <select>...</select><span class="sf-separator">:</span> >> <select>...</select> >> </span> >> >> (There is whitespace here for legibility but of course there should be >> no whitespace between the elements.) >> >> Now we can target .sf-date and .sf-time, and also target .sf-date >> .sf-separator and .sf-time .sf-separator. >> >> The use of 'span' here is important. Any other element would be highly >> likely to have non-BC impacts on reasonably well written CSS (or even >> unstyled HTML). You can't suddenly make a div out of something and >> have folks discovering that there's a line break between the date >> widget and the time widget that they did not intend and did not have >> before updating Symfony. >> >> 'span' is safe because it is well understood to be an element whose >> only purpose is to allow ids and classes to be associated with a run >> of inline content (which HTML5 has renamed "phrasing" content), >> otherwise leaving it alone. Aggressively styling all naked span >> elements in the entire document is widely understood to be a bad >> choice. (: So we shouldn't have to worry that the mere presence of a >> span will change the appearance of pages. >> >> Also, the select element is inline/phrasing content in both HTML 4 and >> HTML 5, so it's appropriate to enclose in a span. >> >> With these changes it becomes possible to replace these composite >> widgets cleanly through progressive enhancement or style them >> reasonably well as they are. It would be better to be able to override >> some of their defaults for an entire project, notably the interval >> between choices on the minutes selector and the choice of separator, >> but if we can't have that, this is still a huge improvement. >> >> One more concern: some people want to make sites whose connection to >> Symfony (or any particular development tool) is invisible. If that is >> an issue then the sf- prefix for the class names could be made >> configurable via settings.yml. The vast majority would leave it set to >> sf-, I imagine. >> >> Thanks again for looking at the possibility of improving the markup >> for the composite date and time widgets. If there are any other >> composite widgets in Symfony I'm not thinking of, it would be a good >> idea to apply the same review to them to make sure they can be >> effectively styled. >> >> On Wed, Sep 1, 2010 at 4:13 PM, Fabien Potencier >> <[email protected]> wrote: >> >> On 8/27/10 6:30 PM, Tom Boutell wrote: >> >> Marijn, the basic time and date widgets are a miserable user >> >> experience and their lack of reasonable structure (there's no >> >> containing element to attach your progressive enhancements to) makes >> >> it extremely difficult to enhance them across your entire project >> >> unless you manually override every single widget, which defeats the >> >> purpose of Doctrine forms. >> >> Why not just fix this problem instead of inventing something new? I would >> >> happily change the default HTML if it makes sense and if it is BC. >> >> Fabien >> >> -- >> >> 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 >> >> >> >> >> -- >> 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 >> >> -- >> 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 >> > > > > -- > 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 -- 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
