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