Alright, well now I'm even more confused. The Admin class is being moved out of the model, but the display information will remain on individual fields so that newforms can use it via form_for_model() and form_for_fields()?
That doesn't make a whole lot of sense to me. I would think that with the newforms admin stuff it would be an ideal time to completely remove all display-related information from the models. It really just doesn't belong there. On Apr 12, 1:22 pm, "jp" <[EMAIL PROTECTED]> wrote: > I feel a bit ashamed. I came across a post about the newforms-admin > stuff and one of the prime goals is to move the admin information out > of the model. > > Yay! I guess I will be writing my code with that in mind from here on > out. > > On Apr 12, 12:50 pm, "jp" <[EMAIL PROTECTED]> wrote: > > > Oh, in addition I was wondering what the 'right' way to do this would > > be at the current time? > > > 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
