On 10/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 10/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Check out my latest version (which I attached to another message to
> this thread). It lets you pass a 'widget' parameter to any Field to
> designate the default widget. It can be either a Widget class or
> instance. Does that do the trick for ya?
I think so. I think I was on the wrong track before - I was thinking
that Widgets would need to be registered with Fields for which they
are appropriate. I see now that you are aiming to allowing _any_
widget to be displayed with _any_ field. +1 to this; sorry for
waffling off in the wrong direction.
The static nature of the as_ calls still troubles me a little.
as_widget can't be called from template, so the only way to access a
custom widget is to make it the default. If we are trying to allow any
field to use any widget, this seems a little artificial.
One of the ideas from the original thread that I didn't really
consider fully until now was to use the template filters for this
purpose. {{ form.name }} renders using the default widget, {{
form.name|as_text }} calls BoundField.as_widget(TextWidget()). A few
short helper functions to register widgets, and you remove the need to
'bless' the built in widgets with as_ methods in the BoundField
implementation.
> This is quite complicated, and I can smell the YAGNI from about a mile
> away, so I'm -1 on this proposal. Let's add it only if there's a
> strong desire/need for it in the future; it wouldn't be a
> backwards-incompatible change.
I'll grant that the full solution I suggested is complex, and probably
YAGNI; if you really have two widgets with different types of input,
defining a different field isn't out of order. I retract my request
for the to_python refactor.
However, the original use case is very real for me - lat/long, color
selection (via multiple widget types), and duration (in days, hours,
and minutes) are all widgets that I have needed in very recent memory.
The 'extract' method provides a fairly simple way to accommodate
to_python implementations that require multiple POST values to compose
a single database value.
If the complexity of the default case is the issue, we could shortcut
the default case by checking for the existence of an extract member
and just using data.get(name,None) if it doesn't exist.
Alternatively, I'll take any suggestions on how to represent multiple
input values->one database value using the code as it stands. The only
option I can see is to do it in javascript; put a hidden input on the
form, with three visible inputs, and write javascript so that whenever
the inputs are modified, the hidden value is modified - but I _really_
don't like that solution.
> 1. We override django.forms with this new module and leave the old one
> in at django.oldforms, so that immediate breakage can be fixed easily
> by changing import statements.
>
> So I guess my preference is for option #1. As for tagging post-0.95
> bugfixes, sure, we can do that -- doesn't matter much either way IMHO.
Works for me. Acutally, we could kill two birds with one stone; check
your prototype in as django.newforms, and when we go live, tag 0.96,
move django.forms to django.oldforms, and django.newforms to
django.forms.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django 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/django-developers
-~----------~----~----~----~------~----~------~--~---
