[Baypiggies] Django | Clean Design Question

Glen Jarvis glen at glenjarvis.com
Mon May 11 20:30:01 CEST 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20090511/81a3fabd/attachment.htm>


More information about the Baypiggies mailing list