On 10/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > However, I'm not so keen on the combination of Field.widget with the > hardcoded as_text, as_textarea approach suggested by the commented > sections of BoundField. I would suggest that these methods are > describing which widget should be used, and as such, should be dynamic > based on the widgets available on a Field: > [...] > This means each Field can define the widget types that are useful and > expose them through the template. The constructor for a Field might > also be extended to allow users to easily add their own widgets to the > available list.
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 would also suggest that the coupling between to_python and the POST > dictionary be loosened. Specifically: > > - Add an extract method be provided on the Widget to describe how to > pull POST data for the Widget out of the POST dictionary. > [...] > - Modify the call to field.to_python to use extract(): > [...] > Why? So that you can implement widgets that use multiple input fields > to produce a single output value. For example: > - specifying color as three separate R,G,B text fields/sliders, but > stored as "#RRGGBB" in the database > - a latitude/longitude entered as degrees, minutes and seconds but > stored as a float in radians in the database. > [...] > However, this means that to_python must be smart enough to use the > provided kwargs to identify what type of data has been provided. If > two different widgets on a field extract different data, to_python has > to be extra smart. To overcome this, let the widget define the > to_python implementation that is compatible with the widget: > > class RGBSliderWidget(Widget): > to_python = 'to_python_from_triple' > def extract() ... > def render() ... 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. > > - Always render the original input data, even if the field was > > valid and got converted to something slightly different by > > to_python(). > > +1 to this option for me. The BoundField is bound to raw data. It > should display that raw data. Especially in the case of __str__, since > it is providing the default widget rendering for templates. > > The other two options smell like magic. You will never know whether > you have converted data or not; predictability goes right out the > window. Good point about the magic. This option sounds like the right solution. > One management issue that concerns me: Is there a plan for getting > this into trunk without messing with installations that are currently > using trunk? This is a biggish API change if it overlaps the existing > django.forms. Were you planning on tagging a 0.96 (or a 0.95.1) > release to capture bugfixes in the post-0.95 trunk? Two options come to mind -- 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. 2. We use a new namespace for this new framework, leaving the old one in for temporary backwards compatibility. Problem is, django.forms is the name that makes the most sense for this sort of thing, and it's not worth having an inferior namespace for the newer and better stuff only for reasons of backward compatibility. 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. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
