Skip to content
This repository has been archived by the owner on Mar 30, 2021. It is now read-only.

zerok/django-oopviews

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

django-oopviews

Base-implementation

In some instances you end up producing tons of views that actually do mostly the same except for perhaps one or two lines. This module offers you a simple alternative:

from django_oopviews.base import create_view, BaseView

class View1(BaseView):
    def __init__(self, request, *args, **kwargs):
        # Here you have your common code
        self.my_variable = 1
    def __call__(self, request, *args, **kwargs):
        whatever = self.my_variable + 1
        return HttpResponse(whatever)

class View2(View1):
    def __call__(self, request, *args, **kwargs):
        return HttpResponse(self.my_variable)

view1 = create_view(View1)
view2 = create_view(View2)

In this example, the code in View1.__init__ is shared between View1 and View2, so you don't need to write it again.

If you want to share some HttpResponse post-processing, implement the BaseView.__after__(self, response_obj) method

For more details check out this blog post

Addons

Content-Type-Negotitation with OOPViews

In some situations it comes in handy, to do some content type negotiation to really provide an optimized view for the user depending on what a user's application supports (say WML or HTML or XML over HTML). HTTP/1.1 handles this using the "Accept"-request header to give the user the option, to say what kind of content type she'd prefer or give a list of content types prioritized with a value between 0 and 1.

This abstract view class should demonstrate, how you can easily handle such situations within Django purely in the view code. The idea is pretty simple: Simply use the __call__ method as dispatcher for content-type-specific methods.

To use this code, simply inherit the basic implementation and then specify your content-type-specific methods and register them in the ctn_accept_binding-dictionary:

from django.http import HttpResponse
from django_oopview import ctn

class TestView(ctn.AbstractCTNView):
    ctn_accept_binding = {
        'text/html': 'html',
        'text/*': 'html',
        '*/*': 'html',
    }

    def html(self, request, *args, **kwargs):
        return HttpResponse("Hello", mimetype='text/html')

The ctn_accept_binding-dictionary not only allows you to bind a method to a content-type, but if you set a value to a tuple instead of just a string, it will take the first element of that tuple as a priority value similar to the one used in the "Accept"-handling. This way, you can prioritize methods for the case, that the user requests any type of a given family like for instance 'text/*'.

History

0.2 (Oct 1 2008)

comes as its own library using setuptools and offering with the django_oopviews.ctn module a simple implementation of content negotiation in HTTP using OOPViews.

0.1 (inofficial)

This version only included the BaseView as well as the create_view function and was bundled with the django-zsutils library.

About

django-oopviews provides a simple way to have some object orientation in Django's view layer

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages