On 4/12/07, jp <[EMAIL PROTECTED]> wrote: > > Oh, in addition I was wondering what the 'right' way to do this would > be at the current time?
very nice that you are bringing this up. I am also just waiting for the wholy grale on this one. Since I have tried creating forms from models, fields and all the magic I finally ended up creating my forms by hand and also connecting the data to it by hand, that is not DRY but it allows for most flexibility, which I found to need most of the time. I almost never have a 1:1 relation between the model and the form that feeds the model. So I can very well live with that. Though there seems a structure to be evolving that might wants to be generalized/abstracted. regards Wolfram > On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote: > > Today I needed to do something perhaps not entirely uncommon. I wanted > > to create a form that contained elements from both the User model as > > well as the UserProfile object I had attached to it. > > > > At this point, I had an option. I could either define a completely > > separate new form that had fields relating to each of the correct > > fields and manually setup the correct validation, or I could derive a > > form using newforms.form_for_fields() and select what fields I needed > > from the model. This was attractive to me as the model already had > > validation-related data due to specifying options such as choices that > > the admin app could pick up. > > > > So I ended up doing the former. It wasn't very pretty, but it worked. > > I soon found out, hwoever, that newforms doesn't even bother looking > > at the choices field for a CharField, and renders them as a regular > > text field instead of a select box as I expected. At this point I > > subclassed the form generated from newforms.form_for_field() and > > manually changed the widgets for the fields that I need to. My final > > result ended up being this piece of code. > > > > http://dpaste.com/8382/ > > > > Now to be perfectly honest, this code is very ugly, and it doesn't > > seem Pythonic at all. A freshly defined newform would be much better. > > However, doing so would mean duplicating information in both my model > > and my form. This breaks down DRY. To fix this I could remove all > > validation/display related information from my model, but then the > > admin application won't work. If I want the admin application to work > > I have to intentionally break DRY. > > > > This seems to me to be a very bad spot to put Django in. Not only is > > it confusing to new users (should I derive my forms from models or > > have my forms separate from models?), but it is also mixing up the > > model with the view which is also very bad. > > > > I just observed this, and I think that there needs to be some serious > > thought about this. > > > > > -- cu Wolfram --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
