Odp: Re: signals pre_save vs model's save()

W dniu niedziela, 29 maja 2011, 15:36:13 UTC+2 użytkownik Malcolm Box napisał:

On 28 May 2011 11:05, Mateusz Harasymczuk <mat...@harasymczuk.pl> wrote:

I am thinking about splitting my model's save() method over few signals.

For example, stripping spaces and making string capitalized.

Why would you want to do that?

Because I am writing CRM, and my end users are non-technical ladies :}
And each one of them inputs data in different format (id numbers, phone numbers, dates, names [upper cased, capitalized, lower cased])
Therefore I have to normalize an input to store, and then print contract agreements in normalized way.
You may say normalize via template tags at rendering level.
Yes, but I use those data for example to calculate date ranges and text search.
If someone has an resignation addendum I have to make some other changes to model.
It is easier to normalize them in pre_save or at the save() method
 

 

I have even more sophisticated problems such as making an object field active set to False basing on various parameters from other fields, such as expiration date, or good or bad karma points.

What do you think, it is generally good idea, to keep models file clean out of heavily overloaded save() methods?

If this logic is tied to your model, what is the advantage of moving it out of the save() method in your model definition? 
You would more usefully serve the same purpose by decomposing the save() method into several functions e.g.:

my largest model is about 20 fields length.
where save methods are about at least 50 lines long.

it gives me a mess.

and then there are list_display functions (each is 1 to 3 lines long) which almost doubles fields length and gives me a 150-200 lines length model file, with only 20 fileds

and I have not included comments and docstrings...

Clean, simple and makes it very obvious what you're doing in the save() method. Compare that with the signals version, which will give someone reading the code no clue at all that when they call save() the values of the fields will change.

I can provide a comment in a model file, that normalize functions are stored in signals file.

 

How about making more than one signal pre_save to the same model?

It will work, but it's the wrong approach.

I am not saying this is a good approach,
I am thinking this might be a good solution in my case.

Looking forward to hearing some more opinions.
I might reconsider, if someone points me a better solution, than I am thinking of.


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.