It's viable for Doctrine forms if nobody ever forgets and types doctrine:build. Not sure whether the admin generator would respect it, but I imagine it would since it uses Doctrine forms. Would filters use it?
A factories.yml default for the generator class would sure help. On Wed, Sep 1, 2010 at 8:56 PM, Kris Wallsmith <[email protected]> wrote: > 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 > -- 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
