James Bennett wrote: > For getting access to the object, I believe that when the 'post_save' > dispatcher signal is sent after saving, one of the included attributes > of the signal is the object itself. >
Thanks for the updated (and very much expanded) documentation on django signals. I see how they could provide an elegant way in which to extend a system without having to pass generic callables around. However, I am once again brought back to how to desire to have some sort of developer hook (perhaps sending of new 'post_create_validation' and 'post_update_validation' signals) in the generic views associated with creation, update. I don't feel this could easily be handled by the existing pre_save signal because it doesn't seem to have access to information contained in the request. There doesn't seem to be any current facility for capturing the required information either before or after calling the generic view, which again leads me to think that extending generic views is the right leverage point. Am I alone in thinking that this would provide a very useful capability to generic views? I don't particularly relish the idea of resorting to a gross violation of DRY by copying the create_update.py module into my application for local edits. Of course, I wouldn't Django to incur significant bloat by adding custom features for every wacky requirement an application might have either So if that's what I have on my hands, I understand and would agree then that what's good for me might not be good for everyone else (I don't think that is the case here, but then again, no one ever does...). -- William --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
