After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class.
You could, for example, extend View to be JinjaView, just replacing render_template().
A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
This set of handlers allow one to isolate requests based on the method posted. Normally, in a view, we would do checks for request.method value and update the resource accordingly. This makes the view code pretty messy.
So one way to avoid these check each time is to have a handler method (resource_handler above), that checks for the method parameter and dispatches to the handler withe the prefix <method>_handler_<suffix>.
This also has the advantage of grouping related actions in a particular class. At the same time a new instance of the request handler is not created on each request (as with the google appengine handler?). Yet another advantage is by making the handler methods as class methods, the handler classes can be inherited to add further functionality to a resource "group.
The disadvantage however is the inability to restrict access to a handler method to only particular methods. Eg above the "r'obja/(?P<id>[^\/]+)/delete/" would map to the delete_handler_objects if themethod was "delete" and post_handler_objects if the method was "post". However this can be worked with a different suffix passed to the handler_params method. Infact setting the suffix to "objects_delete" would result in a "delete_handler_objects_delete" handler on delete method and a Http404 on all others.
Another inconvinience is the inability to detect a view handler by simply inspecting the url patterns. However, this information is carried within the handler_suffix and handler_class parameters which may infact provide greater insight into the semantics around the view handlers.
Needless to say, this easily extends rest based accesses.
Would greatly appreciate feedback and improvements.
- django
- views
- class
- methods
This snippet provides two view classes. The two reason I wanted to write this are, 1) Not have to import all the boilerplate code for each view and 2) so I could have the same URL handle loading a persons profile, or handle an OpenID login request without having to write two separate views. (Yes I know it isnt to hard to write my view, check the header and pass it off to the proper handler view, but I think it looks better code wise to have the handler methods all in one class)
The first one is just for normal views conveniently called *View*. The *View* class that lets you do at least 90% of what you can do in a normal view function, but without having to import all the normal boilerplate code first since this class wraps methods around most if not all the *HttpResponse* types.
The second class *StatefulView* maintains its state across page loads This is especialy useful for ajax type calls where you wish to maintain some form of state while the user is doing something but do not wish to make DB calls and do not wish to polute the session with trivial things
**Note:** On my system it maintains state across browsers and computers as it is not tied to the session, BUT for this to happen all requests must be handled by the same proccess. So requests going to a differing process with not have the state maintained.