Hey Bernhard- I think I may have misunderstood what "empty_value" is supposed to be. I *thought* it was akin to the "add_empty" you see here in sf1: http://svn.symfony-project.org/branches/1.4/lib/plugins/sfDoctrinePlugin/lib/widget/sfWidgetFormDoctrineChoice.class.php. However, now I think that this is somehow more related to Django's meaning for "empty value", which is the value that should be assigned to the field if it is not required but left blank (the paragraph above this: http://docs.djangoproject.com/en/dev/ref/forms/fields/#label). If the latter is the case, I don't see this used or represented anywhere else.
So, what is "empty_value"? Can I remove it :)? Thanks Ryan Weaver Lead Programmer - iostudio - Nashville, TN http://www.iostudio.com http://www.thatsquality.com Twitter: @weaverryan On Tue, Jan 18, 2011 at 6:22 PM, ryan weaver <[email protected]> wrote: > Hey Berhard- > > I think overall, you're right about making as much of the presentation > options available to the designer. At the same time, they have to know what > options to pass, which will still mean that a developer needs to be > involved. Also, what about an option like "disabled" or the "empty_value"? > Those seem just as good of candidates to be passed in as parameters. Also, > since the separator parameter is only used when you've listed preferred > choices, it really feels like we're working hard to make something available > to the designer that just maybe can't be. I do like the parameters in > general - they obviously open up customization. So, separator as a parameter > or inside the ChoiceField - that's the question. I'm slightly more apt to > putting it in the field. > > On the emptyValue, I'll change the getter to behave normally. I don't see > this feature actually doing anything yet, but I'm assuming it's related to > having a blank entry at the top of the select box? If that's the case, it's > worthwhile on CountryField, because it specifies the choices for you. To get > a blank entry currently, you'd need to do: > > $field = new CountryField(); > $field->addOption('choices', array('' => 'Choose a Country') + > $field->getOption('choices')); > > In writing the above, I just noticed one other thing. Are options not meant > to be set after Field construction? I just noticed there is not > *setOption()*, only *addOption()*. > > Overall, I really really like the Form component - it's been a pleasure to > go through its code. > > Thanks! > > Ryan Weaver > Lead Programmer - iostudio - Nashville, TN > http://www.iostudio.com > http://www.thatsquality.com > Twitter: @weaverryan > > > On Tue, Jan 18, 2011 at 8:02 AM, Bernhard Schussek <[email protected]>wrote: > >> Hi Ryan, >> >> > If this is the intended behavior, the separator in ChoiceField should >> > be removed. Is that the intention? >> >> Yes. >> >> > Is the parameters array a >> > nearly-dead feature that should be killed off? If so, this would put >> > the separator into ChoiceField. Is that more correct? >> >> It's nearly dead, but I think it has a valid purpose. Through this >> array, the rendering of a field can be customized in the template. >> E.g., a template designer can change the separator of a field without >> consulting a developer. >> >> Ideally, all options that affect the rendering of a field would be >> passed through this array. Unfortunately that's not possible, because >> often a change in the rendering affects the how the submitted and >> bound data is processed (e.g. the option "widget" in DateField). >> >> What's your opinion on the best solution here? >> >> > It would be useful on ChoiceField >> > subclasses such as CountryField. >> >> Can you explain why? >> >> > Additionally, the behavior of >> > getEmptyValue() only returns a value if the field is *not* required. >> >> This should be changed. getEmptyValue() should return the value of the >> option, no matter whether required or not. >> >> >> Bernhard >> -- >> Software Architect & Engineer >> Blog: http://webmozarts.com >> Twitter: http://twitter.com/webmozart >> >> -- >> 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]<symfony-devs%[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
