Have you tried utilizing the event I suggested earlier? Kris On Sep 1, 2010, at 6:42 PM, Tom Boutell wrote:
> 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 -- 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
