> > I already have one specific piece of API feedback: the current > implementation requires that all view logic is contained in GET(), > POST() etc style views. This is fine, except for the fact that there > are occasions where GET and POST share a lot of common logic. It would > make sense to me to allow for a request() method that is the direct > analog of how we do views right now, wrapping lines 53-59 of base.py > into a request() method. This would allow users to define their own > dispatch mechanisms, or share logic between GET and POST (and any > other http method) as necessary. >
I'm currently using a very similar approach for class-based views except in my request() implementation I use the request.method and look at self for an attribute with the method name uppercased. if it isn't found an HttpResponseNotAllowed is returned and the list of permited methods is built from checking the view instance for the known methods. Here's an example of the constructor and request implementations: http://gist.github.com/605801 . I have simplified my code for clarity so I may have introduced some bugs. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
