Hello All, Given the scope of things this may actually be irrelevant at the moment but I've created a patch that adds an exact_length option to CharField. I am aware the same result can be had by setting max_length and min_length to the same value. Patch attached.
Cheers.
On 10/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> 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 %-)
>
> >
>
--
Nesta Campbell
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
validator.patch
Description: Binary data
