Alex Gaynors talk at EuroDjangoCon will probably help you out with some handy Form tips. The slides are here; http://lazypython.blogspot.com/2009/05/eurodjangocon-2009.html
The video should be online somewhere at some point. Cheers, Dougal --- Dougal Matthews - @d0ugal http://www.dougalmatthews.com/ 2009/5/12 Glen Jarvis <g...@glenjarvis.com>: > Since I've been using Django this past year, I've slowly learned how to be > more dynamic and DRY using the Django framework. > For example, in the very beginning, if I were using newforms (now forms), I > would create a form that mimic'ed the model (unless modelforms were really > easy). > Now, I've been using model forms and doing something like this for quite a > while: > from django.forms import ModelForm > class PIGDemoForm(ModelForm): > class Meta: > model = Grant > def __init__(self, *args, **kwargs): > super(PIGDemoForm, self).__init__(*args, **kwargs) > self.fields['date_received'].widget =\ > forms.TextInput(attrs={'class': 'date-pick'}) > ...etc... > > Now, I have two models, we'll call model1 and model2. And, they both have a > name attribute. Because I normalize data, I never do something like > "model1.model1_name", but instead "model1.name." But, it's getting me in > trouble. > Both forms have a 'name' attribute. And, both forms are in a template > together. (I mean that both form instances are created for the specific > instance of the model in question, and are displayed together (very > interleaved) in a template). The response that I get back, via request.POST > instantiates both forms: > form1 = Form1(request.POST, instance=blah1) > form2 = Form2(request.POST, instance=blah2) > [Note I'm translating this from a domain specific problem to generic (form1, > form2, etc.) on the fly. There's room for error] > Now, if request.POST has only one 'name' then form1 and form2 are getting > the same name, obviously causing a problem. > My question is specific to a better design. I see the following options (did > I miss any): > 1) Manually create one form that mimics model1 and model2 together (violates > DRY, and makes verbose and less useable code) > 2) Change my model names to be something like (model1.model1_name, > model2.model2_name). This violates normalization rules (and has an impact on > other code already written). > 3) Try 'hacking' the form temporarily... something like: > def __init__(self, *args, **kwargs): > super(blah blah blah) > blah blah > self.fields['grant_name'] = self.fields['name'] > If this third option is chosen, I need to either: > a) move the self.fields['grant_name'] back to self.fields['name'] > before using the form shortcut save() method, [and I scratch my head on how. > Do I need to look at the pre-save signals, etc.] > b) Create a new model manually, specifying a mapping of > "self.cleaned_data['grant_name']" to the model's "name" property. This has > the same feel (redundant and less dynamic) as the above solutions, but may > be the best we can do in this situation. > Please note that the database is laid out in a very normalized manner per > the request of the IT department of my customer. The user, however, doesn't > understand these differences *at all* and just wants his data to look like > it does when he types in a spreadsheet. So, there are competing design > paradigms coming from two different people. That difference is something > we're going to have to live with in this design. > When I start getting into this kind of place, I think it's time for me to > stop, put the keyboard down, and think... This is a very common design > pattern: what do most people do? > > Thanks for listening and any fresh perspective would be welcomed. > > All the best, > > Glen Jarvis > -- > "You must be the change you wish to see in the world." -M. Gandhi > > > > --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
