Re: Callable hooks for generic views after validation with no errors?

2006-10-05 Thread wam

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
-~--~~~~--~~--~--~---



Re: Re: Callable hooks for generic views after validation with no errors?

2006-10-05 Thread Malcolm Tredinnick

Hey James,

On Thu, 2006-10-05 at 10:12 -0500, James Bennett wrote:
> On 10/5/06, John Melesky <[EMAIL PROTECTED]> wrote:
> > Does that mean it's ready for inclusion in the django docs tree? It
> > would be nice to get topics like this covered in the core documentation.
> 
> If one of the committers thinks it's good enough, then by all means.
> I'll happily submit it in ReST format. Might also be a good idea to
> just leave it on the wiki for now, so people have a little time to add
> to it, correct any mistakes, etc.

I was going to leave it for a couple of days or so to let it crystallise
in case you or anybody else wanted to add stuff. It should go into core
sooner or later, but there's no huge rush that I can see.

So keep tweaking it until you're happy and then you or I can convert it
and I'll commit it.

If you get keen and want to convert it to RST quickly, just drop it in a
ticket assigned to me. There are a couple of docs bugs I am going to
look at over the weekend, so I'll get to it in the next couple of days.

Cheers,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Re: Callable hooks for generic views after validation with no errors?

2006-10-05 Thread James Bennett

On 10/5/06, John Melesky <[EMAIL PROTECTED]> wrote:
> Does that mean it's ready for inclusion in the django docs tree? It
> would be nice to get topics like this covered in the core documentation.

If one of the committers thinks it's good enough, then by all means.
I'll happily submit it in ReST format. Might also be a good idea to
just leave it on the wiki for now, so people have a little time to add
to it, correct any mistakes, etc.

-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Callable hooks for generic views after validation with no errors?

2006-10-05 Thread John Melesky

James Bennett wrote:
> On 10/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>> There is some documentation on how Django's signals system works and how
>> to hook into it here: http://code.djangoproject.com/wiki/Signals
> 
> I just went through and completely re-wrote that to cover signals in
> as much detail as I could muster.

Does that mean it's ready for inclusion in the django docs tree? It
would be nice to get topics like this covered in the core documentation.

-johnnn



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Callable hooks for generic views after validation with no errors?

2006-10-04 Thread wam


James Bennett wrote:
> This is probably the way to do it; adding special-case hooks to the
> generic views doesn't sound like a good solution to me.

Well, callables  which can be sent into generic views and are executed
just prior to handing off to the template in order to populate
additional context to the form. I'm trying to get (near) equivalent
functionality to occur just prior to the database save. I certainly
wouldn't call it an elegant solution, but  the status quo doesn't seem
to provide this functionality which is even less elegant. I'd ideally
like to see the generic views for creation and modification of an
object  be powerful enough to be used for the admin interface, but
without some way of attaching functionality into the view prior to key
events like object saves, I think generic views just don't have the
power at this point.

Another use case for this kind of functionality might be to perform
auto slugification for fields, so that end users wouldn't have to
create their own slugs.

> 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.

Yes, but you'd still have to associate that with with the request
object that was passed to the generic view so that the user id of the
creator/modifier of the object can be associated with the log record.
It also wouldn't seem to give an indication of what the object's state
was before being modified.

I guess I see the fact that  a callable can be sent into a generic view
to be run as part of the extra_context parameter as a usefull pre_ hook
for a generic view when the view is called as a 'GET' and I'm wishing
similar functionality existed when the view is called as a POST.

  -- 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
-~--~~~~--~~--~--~---



Re: Re: Callable hooks for generic views after validation with no errors?

2006-10-04 Thread James Bennett

On 10/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> There is some documentation on how Django's signals system works and how
> to hook into it here: http://code.djangoproject.com/wiki/Signals

I just went through and completely re-wrote that to cover signals in
as much detail as I could muster. I *think* I've got them all
documented in there now, but if anybody sees a signal I missed, please
add it to the list on that page.

I hope Tyson won't mind that I pretty much left nothing of his
original write-up...

-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Callable hooks for generic views after validation with no errors?

2006-10-04 Thread James Bennett

On 10/4/06, wam <[EMAIL PROTECTED]> wrote:
> The closest I've been able to figure out is to create a custom view and
> call create_object from my view. Then, depending on whether the
> returned object from create_object is an instance of
> HttpResponseRedirect() I can determine if the addition/edit was
> successful; however, I still don't have access to the new/editted
> object.

This is probably the way to do it; adding special-case hooks to the
generic views doesn't sound like a good solution to me.

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.

-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Callable hooks for generic views after validation with no errors?

2006-10-04 Thread wam

I make extensive use of generic views in one of my apps. Now that the
app is nearly finished, I'm being asked to do change tracking/audit
trail on the objects managed in the generic views. Recognizing that I
could just create and save django.contrib.admin.models.LogEntry()
objects and possibly create a view or two to view only the audit
records associated with my application. The trouble comes in from not
having a particularly good insertion point to create the LogEntry()
objects while using a generic view.

The closest I've been able to figure out is to create a custom view and
call create_object from my view. Then, depending on whether the
returned object from create_object is an instance of
HttpResponseRedirect() I can determine if the addition/edit was
successful; however, I still don't have access to the new/editted
object.

I did consider creating a custom view that would be called via access
to a URL accessed as result of a post_save_redirect parameter on the
generic view; however, I'm uncomfortable depending upon a redirect to
create audit records. For one, it'd be easy for a browser to disregard
the redirect in order to avoid log creation. Additionally, it would be
easy to "forge" audit records by direct access to the URL attached to
the audit records creation view.

Would it be possible to add a generic view parameter along the lines of
'post_save_hook' which is expected to be callable object which is
passed the newly created object (in the case of create_object()) and
ideally a copy of the original (non-updated) object along with the
updated object in the case of update_object. These hooks would only be
called in case of a successful model validation and database save.

If there is agreement that the post_save_hook would provide value and
is the proper way to accomplish what I would assume is a fairly common
need (do something with the newly updated/created object from a generic
view), then I'll go ahead and submit it as a bug feature and may even
be able to submit a patch along with the request.

  -- 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
-~--~~~~--~~--~--~---