> Given this control flow let's try to do some of the typical > modifications mentioned above: > Authorization: > Django has a beautiful mechanism for authorization, which is using > decorators (@may_do_a_b_or_c) directly in the views.py. > Tempting, but will not be modifyable in any way once you lift the app. > (because the decorator will become tied to the view function). Other > mechanisms are not presented (in a standardized way). If anyone has > ideas about this I'd love to discuss them.
The fact that the decorator @ syntax is so convenient sometimes makes people forget the fact that it is only syntactic sugar. You do not have to use it, and specifically for the purpose you describe it is a really bad idea. When dealing with authorization, using this syntax ties you up and doesn't give the convenience of having authorisation declared in a more centralised location. An alternative approach I use is to centralise authorization is to not use the @ decorator syntax, and use the decorator directly in urls.py. E.g. from one of my apps: ----------- from django.conf.urls.defaults import * from babystats import views from django.contrib.auth.decorators import login_required urlpatterns = patterns('', url(r'^$', login_required(views.user_babies), name='babystats_user_babies'), url(r'^(?P<id>\d*)/$', login_required(views.show_baby), name = 'babystats_baby_detail'), #etc... ) ----------- This is a start. You can always replace the app's urls with your own and apply different decorators/access controls. It just requires you to include your views as callables instead of strings. If you want to do it even more globally, I don't think it should be too hard to write a function to replace django.conf.urls.defaults.include that takes a decorator as a second parameter and applies it to all the included views, e.g. it could be used: (r'^path/', include_decorated('appxyz.urls', my_decorator)), Carles -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.