Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages)
I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order.
This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
This trick is for caching a view only if it passes some condition, for example, if there are more than zero items in a list. The same methodology could be used for conditional applying of other decorators.
If you use decorators to views, it will greatly improve readability and extensibility of your code. I'm using a couple of decorators like this to reduce complexity and redundancy in my view codes.
`wraps` from Python 2.5's standard library make the attributes (name, docstring, and etc) of the decorated function same to those of `view_func` so that it could be easily recognized when you run `./manage.py show_urls` or debug.
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.
Yet another implementation of class based RESTful dispatch. This particular implementation features:
* You do not have to call __init__ from the derived classes.
* Avoids __metaclass__ which (in our environment) led to unexpected method override behavior.
* Method names match the google webapp API.
* One new instance per request to reduce errors in multi-threaded code.
Snippets of inspiration:
* [436](http://www.djangosnippets.org/snippets/436/)
* [437](http://www.djangosnippets.org/snippets/437/)
* [1071](http://www.djangosnippets.org/snippets/1071/)
* [1072](http://www.djangosnippets.org/snippets/1072/)
* [1226](http://www.djangosnippets.org/snippets/1226/)
This example shows, how to use database views with django models. NewestArticle models contains 100 newest Articles. Remember, that NewestArticle model is read-only. Tested with mysql.
Slightly shonky implementation of a custom URL shortening view, as [described on my blog](http://simonwillison.net/2009/Apr/11/revcanonical/). Depends on [baseconv.py](http://www.djangosnippets.org/snippets/1431/)
This snippet is working code, however it is not intended for proper use, rather to garner comment on an alternative style of view - using a class for views, rather than a function.
While working with views, I've often felt that the traditional django code layout splits concerns in an unnatural fashion. The parameters for a view must be maintained in both the urls file as well as the view for example, and there is no neat way of grouping multiple accessor for a REST resource.
This 'shim' code aims to propose an alternative architecture, that is interchangeable with the existing system.
Rather than include a tuple of urls, instead a list of classes is provided. Each class models a resource, or page.
Page objects have a url property and name property, so it is therefor trivial to reconstruct the url tuple from the class, but allow more simplicity and structure in relating the methods of the resource.
You may notice that this structure closely follows the architecture of the web.py framework - this syntax did indeed play a part in the concept for such a structure.
While this paradigm may not be suitable in all situations, I believe it promotes a simpler, more encapsulated views architecture.
Any comments and feedback are welcomed.
Example usage (untested, sorry):
class Homepage(Page):
def get(request):
return HttpResponse("Hello World")
urlpatterns = patterns('',
Homepage,
url('^existing$', existing.view.function, name = "foo"),
)
Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request.
class View(Request):
def DELETE(self, request):
...
def GET(self, request):
...
def PUT(self, request):
...
Other snippets provided inspiration:
* [436](http://www.djangosnippets.org/snippets/436/)
* [437](http://www.djangosnippets.org/snippets/437/)
* [1071](http://www.djangosnippets.org/snippets/1071/)
* [1072](http://www.djangosnippets.org/snippets/1072/)
The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).
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.
Take the legwork out of processing forms.
Most people have a very specific structure to how they process forms in views. If the request method is "GET", then some HTML (with the blank form) is rendered. If the method is "POST", then the form is validated. If the form is invalid, some other HTML is displayed. If valid, the data is submitted and processed in some way.
In order to do this all in a much nicer way, simply subclass `FormHandler`, define three methods (`valid`, `invalid` and `unbound`), point to the form, and use the subclass as your view in the URLconf.
Here's an example of writing generic views in an object-oriented style, which allows for very fine-grained customization via subclassing. The snippet includes generic create and update views which are backwards compatible with Django's versions.
To use one of these generic views, it should be wrapped in a function that creates a new instance of the view object and calls it:
def create_object(request, *args, **kwargs):
return CreateObjectView()(request, *args, **kwargs)
If an instance of one of these views is placed directly in the URLconf without such a wrapper, it will not be thread-safe.
I recently got a form working via jQuery and Django. This was not easy for me to do and I thought I'd record my finding here.
The form submits via jQuery and the "form" plugin. Please visit jQuery's home page to find all those links.
This code handles:
* urls.py -- passing both normal and 'Ajax' urls to a view.
* views.py -- Handling both kinds of requests so that both normal and ajax submits will work.
* The HTML template with the script for submitting and some bling.
Error handling
===
I like to stay DRY so the idea of checking the form for errors in javascript *and* checking it in Django irks me. I decided to leave that up to Django, so the form submits and gets validated on the server. The error messages are sent back to the browser and then displayed.
This is a ModelForms-based rewrite of the create_object and update_object generic views, with a few added features. The views now accept a "form_class" argument optionally in place of the "model" argument, so you can create and tweak your own ModelForm to pass in. They also accept a "pre_save" callback that can make any additional changes to the created or updated instance (based on request.user, for instance) before it is saved to the DB.
Usage: just save the code in a file anywhere on the PythonPath and use the create_object and update_object functions as views in your urls.py.