As you might have guessed based on the recent activity in django-zsutils, this project is more or less a dumping ground for some ideas I have and snippets I use on multiple sites (or at least see myself using on multiple sites). The new step for any of these is, whether I can see them as standalone library. If I do, I try to clean them up even more and split them of the main package.
This happened yesterday to my little object-oriented views-implementation for Django. If you don't know this library yet, please take a look at its README or this blog post. Basically, the idea is to be able to share some common functionality between views by making views out of Python classes.
Today I did some final cleanup, moved it over to setuptools and finally made an actual 0.2.0 release including PyPI-registration, files etc. So if you want to use it, just run easy_install django-oopviews :-)
I also registered the project on launchpad.net, so if you find any bugs or have some feature request or other questions, please ask there :-)
I see the call thing for OO views quite a lot latly... what is the benefit of using this approach in contrast to extending the HTTPResponse Class?
We are in the process of going OO views but haven't settled yet on which method to use... using call, extending the HTTPResponse or even the URLPatterns
Oct. 2, 2008, 2:03 p.m.
I see the call thing for OO views quite a lot latly... what is the benefit of using this approach in contrast to extending the HTTPResponse Class?
We are in the process of going OO views but haven't settled yet on which method to use... using call, extending the HTTPResponse or even the URLPatterns
Oct. 2, 2008, 2:03 p.m.
In the end it's just a different approach. I prefer keeping views as something that produces a HTTPResponse in contrast to something that is an HTTPResponse. For me the response is just a way to serialize data and should actually not really produce anything by itself.
Oct. 2, 2008, 3:06 p.m.