Hi Tobia !
Could you post a link to a place where class-based views are being
criticized ? And also in what sense are they convoluted ?
Personally, I have started using the class-based views heavily as soon
as they were released, and I think they are great. Very flexible.
However, I'll tell you what I usually do (and if you don't, it's just
not possible) : browsing the Django code online, every time I need to
customize a view. So in my sense, there is much more room for
improvement in the class-based views docs than in their actual API ...
Sébastien
On Dec 3, 8:56 pm, Tobia Conforto <tobia.confo...@gmail.com> wrote:
> Hello
>
> As you may know, current class-based views have been criticized for
> their complexity.
>
> Their design is a bit convoluted and difficult to understand by the
> average view author and therefore any work made with them may hide
> sneaky bugs.
>
> On top of that, it's difficult to apply common decorators to them. The
> recommended approach seems to be to apply them to the dispatch()
> method. But this requires overriding that method even when the base
> dispatch strategy is otherwise adequate, and converting the decorators
> with method_decorator(). This is ugly and is only a partial solution,
> as method_decorator() doesn't currently support decorators with
> arguments, such as @user_passes_test(a_test).
>
> All this is unfortunate, because there is a clear need for a simple,
> Pythonic object-oriented approach to view authoring, to achieve
> separation of concerns and code reuse. Dispatching by http method (one
> of the basic features of class-based views) is also a growing need, in
> the world of AJAX and REST-based web applications.
>
> I have attached my proposal for a slight change in the design of class-
> based views. It is similar in purpose to the existing ones, but much
> simpler to use and to extend.
>
> Examples speak louder than words:
>
> --- urls.py ---
>
> urlpatterns = patterns('',
> url(r'^(\d)+/$', views.Article),
> )
>
> --- views.py ---
>
> @login_required
> class Article(View):
>
> def __init__(self, request, pk):
> super(Article, self).__init__(request, pk)
> self.pk = pk
>
> def get(self):
> article = get_object_or_404(Article, pk=self.pk)
> return render_to_response('hello.html', {'article': article})
>
> def post(self):
> return HttpResponse('You posted something but I threw it
> away.')
>
> ---
>
> Points of note:
> - the usage in urls.py is now indistinguishable from regular views;
> - subclasses may extend __init__ to make use of request parameters;
> - the dispatch logic, based on http method, is hidden in the base
> class;
> - standard decorators may be simply applied to the class (Python >=
> 2.6)
>
> Here is the View base class:http://dpaste.com/hold/665528/
> It's very simple, even shorter than the existing implementation.
>
> I haven't taken the time to translate the whole django.views.generic
> package to this new design, but I will do so shortly, assuming I get
> some kind of positive feedback. The existing functionality (the
> various generic views and mixins) should be fairly easy to port to the
> new design.
>
> This is a slightly different design, so there are bound to be a few
> incompatibilities. For example in my code the dispatched methods (get,
> post...) don't receive the request object and parameters, because they
> were already passed to __init__ and it wouldn't make sense to pass
> them again.
>
> I'm not familiar with Django practices about backwards compatibility.
> If it's really important not to break old code, I guess the new style
> classes could be made to keep the same interface as existing ones,
> including a dummy as_view() method. But it would pollute the code with
> old cruft. Or they could be implemented in a new package. I need
> further directions on this issue.
>
> -Tobia
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
