Kevin Dangoor wrote:
>
> I think "options" should only exist for select fields. Otherwise, a
> widget should use named parameters for the things that are of
> interest/value to it.
>
The problem is passing them along the way from a form container to it's
fields at display time, if we know that we can always rely upon "value"
and "options" (as it is now) being passed by a form (or another
compound widget) to it's fields we can just use them in a general way
for passing dynamics things (in this case a SelectField is a special
case that uses them for collecting possible choices).
field.display(value=value.get(field.name), options.get(field.name,
{}))"
That's what ended up on my last patch, r629 (maybe you didn't notice it
:P).
In this way you need to construct a options dictionary along with the
value one that you pass to the template from your controller.
Other solutions?
> One thing that may be useful to do is allow you to put a list of
> widget attributes that you'd like to make available to the template
> and have that do the equivalent of:
>
> d[that_attribute] = d.get(that_attribute, getattr(self, that_attribute))
>
> That would make all of these types of things overrideable at display()
> time. We could, if it's desirable, make that automatically call a
> callable, but I'm a bit less certain on that one.
>
Yep, that could be useful, I've done something similar for the last
patch on #490 (attributes support), but we should also take care of
mutable (list/dict) instance attribute.
A shortcut like the one you mentioned could be useful.
>
> Thanks for writing those tests! That was a big help! Always nice to
> know that more of the functions are tested.
I'm getting addicted to write tests, it's a nice feeling when they
pass. :-)
>
> > Great work by the way.
>
> Thanks, and same to you!
>
:-)
Ciao
Michele
