Malcolm, Thanks for the quick understandable response.
So in order to this I would create two classes: - one a widget class that overrides render method - to create the comma delimited string from the value ( a list of string ) sent. - one a field class that overrides the clean method - to create the list of strings from the widgets value. Dan On May 17, 3:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2007-05-17 at 11:58 -0700, Dannoo wrote: > > I have a few questions about the best ways to extend the Field and > > Form classes that are part of django newforms. > > > For example, create a Field that is like a charField but gets a list > > of strings which should be rendered as a comma delimited in the text > > widget. When that filed is cleaned the comma delimited list of > > elements is parsed and returned as a list of strings. > > > Issues: > > The Field class has a clean function that gets the widget's data, > > validates it and converts it into a usable python type. Shouldn't > > there be also be a Field function (unclean?? ), that takes data and > > converts it into a type that can be used by the widget? > > The form that the widget wants to use for presentation is a widget > issue, not a field issue. Use the render() method on widgets to do this > processing. > > Before you start wondering if this is inconsistent (why isn't the widget > responsible for turning the data into something a field can use in the > reverse case?), it isn't. There is also value_from_datadict() on widgets > that puts the responsibility for converting funky data formats into > something the Field subclass can use squarely into the widget's area of > responsibility. > > > > > It seems like there is three different ways of getting data into the > > fields. > > Two, not three, but there isn't any real redundancy here, either. The > two methods are used at different times in the creation process in order > to provide different levels of access (whether you are working on a > field-by-field basis or with the form as a whole). > > > 1. the Field's initial data. > > Mostly used for providing suggested initial values when constructing > field-by-field (e.g. from a model). Overridden by any data passed in at > the Form level, which supports the (quite valid) notion that Field-level > initial data is just a fallback initial value that is of lower value > than data passed into the form itself. > > > 2. the Form's initial data. > > Mostly used when filling a form with data in a holistic fashion. For > example, when you are processing form input and using that data to > create a form instance you can validate and work with. > > > 3. the data in a bounded Form. > > This is just the data created in step 2. A bound form, internally, is > simply a BaseForm instance that contains data. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
