Hooking command.filter_options and forcing in the additional option to specify the factory class? I will look at that.
On Wed, Sep 1, 2010 at 9:53 PM, Kris Wallsmith <[email protected]> wrote: > 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 > -- 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
