Forgetting namespaces or existing named URL patterns for a moment, the
major difference is that with function-based views, we were giving a
qualified "module.function" parameter to reverse() or {% url %}.
How can we do that with class-based views, without naming every URL
pattern? Or is it not possible?
A side question that's been nagging at me during all this is, will
class-based views become the norm, even in places where we weren't
using function-based generic views? I was using direct_to_template()
in 99% of my views, simply because it was a shortcut for the whole
render_to_response('my_template.html', my_data_dictionary,
context_instance=RequestContext(request)) palaver. In most cases I was
still passing an extra_context, but it was a little bit less
typing ;-)
Another question (sorry - maybe these should be separate posts), how
does one go about using the permission_required() decorator with class-
based views, or something like the following:
@user_passes_test(lambda u: u.is_superuser)
def my_superview(request):
...
return response
Sorry if I'm jumping the gun a little bit. I realise this is a dev
version and is still in flux.
On Dec 7, 2:33 pm, "burc...@gmail.com" <burc...@gmail.com> wrote:
> Hi Daniel,
>
> I'm not core developer, but I
> thinkhttp://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-n...
> should be used.
>
> you can use reverse("yournamespace:someview"), and it's also cool to
> do things like this in settings.py:
>
> reverse_lazy = lazy(reverse, str)
> LOGIN_REDIRECT_URL = reverse_lazy('yournamespace:your_main_page')
>
> Perhaps it's not advertised as it should, and people continue to
> invent their tricky namespace schemes...
>
> On Tue, Dec 7, 2010 at 3:42 PM, Daniel Swarbrick
>
>
>
>
>
>
>
>
>
> <daniel.swarbr...@gmail.com> wrote:
> > I have been tracking the development of class-based views for a few
> > weeks now, and am just starting to adapt some of my work-in-progress
> > sites. This post is in a bit of a grey area between django-users and
> > django-developers, but I'm curious what is suggested for sites that
> > make heavy use of django.core.urlresolvers.reverse() and {% url %} in
> > templates.
>
> > Obviously with the old function-based views, we could simply do this:
>
> > from django.core.urlresolvers import reverse
>
> > def my_view(request):
> > ... do something useful ...
> > return response
>
> > my_view_url = reverse('my_app.views.my_view')
>
> > And likewise we could also reference that view using the {% url %} tag
> > in templates.
>
> > What is the recommendation for using reverse() and {% url %} when we
> > migrate to class-based views? So fat the only solution I have come up
> > with is naming the the URL patterns in urls.py, for example:
>
> > urlpatterns = patterns('',
> > (r'^$', TemplateView.as_view(template_name='main/index.html'), {},
> > 'home'),
> > )
>
> > In the above case, we can now reverse('home') or {% url "home" %} -
> > but is this the only way? If so, one would have to give some careful
> > thought to the names of the URL patterns, so that it was readily
> > obvious what view each named URL actually was. For example, one might
> > end up using names like "myapp.IndexView" - a pseudo-hierarchical
> > naming scheme, to essentially bring us back to the place we were with
> > function-based view names.
>
> > I look forward to people's ideas about this...
>
> > --
> > 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
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
--
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.
