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 django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
