Considering the point is to be able to build reusable apps, I have to agree that there must be a clean way and I am guessing we are not the only ones who've found a need for this ;) I need to read over this a bit more to really get it. I just read about callback functions so it's kind of a new concept to me. I was thinking that since everything is an object I could write the wrapper like you write it for generic views in general so I guess I am still missing something. I will do some more research and if I find an elegant solution somewhere I'll post back. I really appreciate your response :)
On Oct 17, 11:15 am, bruno desthuilliers <[EMAIL PROTECTED]> wrote: > On 17 oct, 16:18, Heather <[EMAIL PROTECTED]> wrote: > > > I have a couple of projects that use the same application > > (particularly, photologue). In one project, I want the views of the > > imported application to require users be signed in. All the views in > > this imported application are generic. So, is it possible to use > > login_required w/o having to go into photologue.urls and add the > > decorator? Is it possible to do this in my projects urls file? > > Technically, yes - but I failed to find a clean way to do so. Here's > some possible (*untested*) hack: > > # project's urls.py > > import photologue.urls > for purl in photologue.urls.urlpatterns: > callback = purl.callback > purl._callback = login_required(callback) > > AFAICT, this _should_ work - but well, this is a (dirty) hack, and as > such is not garanteed in any way. > > And if there's a better way (not requiring to rewrite all photologue > urls by hand), I'd be happy to know about it !-) > > > I am > > new to Python so I'm not sure I'm on the right track but I thought I > > should do something along the lines of writing my own wrapper that > > would take photologue.urls as an argument (the **kwargs argument, > > maybe?) Like: > > > @login_required > > restrict_access(*args, **kwargs) > > #if this is indeed the right idea, this is where I'm not quite > > sure what to do... > > if kwargs.list_object(*args, **kwargs) > > return kwargs.list_object > > > I know this isn't right but I am not 100% sure of the concept of > > decorators. > > The first thing to understand is that in Python, everything is an > object - including functions. The second point is that functions are > mostly a specific case of callable objects - a callable object being > any object implementing the __call__ operator (iow : having a __call__ > method). FWIW, classes (classes being objects too...) are callable > objects too (you call them to instanciate them). > > IOW : > - you can use functions and classes like any other objects (passing > them as args, returning them from function, etc, etc) > - you can define your own callable types > > Now : a decorator is a callable object that takes a (single) callable > object as argument and returns a (single) callable object. > > FWIW, the > > @decorator > def somefunc(...): > # XXX > > notation is only syntactic sugar for > > def somefunc(...): > # XXX > somefunc = decorator(somefunc) > > HTH --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
