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
