On 23/10/10 14:28, Luke Plant wrote:
You can do it if you do something like this in your views.py:
my_view = MyView.as_view()
That way you export your view as both a function to be used as a view
directly, and a class for further re-use. If your CBV cannot be used
directly (e.g. needs to be subclassed), then it will have to imported by
someone in order to be used anyway, and they can do the step above. In
some cases, especially where you are simply wanting to include someone
else's app with a small amount of customisation, that brings up the
question of where to put that view definition. One solution is to have a
'project' app which has a views.py all these bits and pieces in it. To
me, that seems like a nicer idea than filling urls.py with bloat.
If this was established as a convention, then the problem with reverse()
would be addressed as well.
Is there a reason we can't extend the URL syntax to be able to refer to
class methods as well? "myapp.views.users.UserView.as_view" is perhaps
ambiguous, but something akin to the entry point syntax in setup.py
might work: "myapp.views.users:UserView.as_view" (obviously keeping the
current way as well).
As for the naming problem, I always, always name my views in the URLconf
- I find that using the class name is just fragile, since you can't
easily rearrange views into a package. The docs are already encouraging
this approach, but perhaps we should make it clearer in the CBV docs?
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
