> No! View callable functions must accept at least a request argument. There will never be something this that will work as a view callable:
This is my typo. I was talking about a regular generic view callable. I still don't get how to rewrite these @authenticate_form and @https (as an example) - https://github.com/Pylons/pylons/blob/master/pylons/decorators/secure.py - to be able to do the common: @view_config() @https() @autnenticate_form def view(request) - or - def view(context, request) - or - def view(self) without passing it to view_config On Thursday, June 21, 2012 2:39:57 AM UTC+4, Chris McDonough wrote: > > On 06/20/2012 06:13 PM, Max Avanov wrote: > > > So I'm lost as to what > > you mean by "no other way to get access to request object" > > > > Because I must > > - either to follow the official approach provided by Michael (" a > > consistent signature no matter whether the actual view is a method, or a > > function > > that accepts either (context, request) or just (request)...") with the > > consequent @view_config(decorator=...) and the chained code snipped. > > - or use the "classic" way: > > @decorator1 > > @decorator2 > > @decoratorN > > @view_config > > def func() > > > > For classic way I use the decorator package - > > http://micheles.googlecode.com/hg/decorator/documentation.html - But > the > > classic way allows me only one generic approach to get the request > > object - via get_current_request, right? > > No! View callable functions must accept at least a request argument. > There will never be something this that will work as a view callable: > > def func(): > ... > > It just wont work. A view callable must be: > > def func(request): > ... > > An alternate view callable signature optionally accepts "(context, > request)" but if your code doesn't use that signature for any of your > view callables, you won't care. Pyramid view callables can also be > methods of classes, but if your code doesn't use view classes, you won't > care about that either. > > If you *do* care about reusing a decorator across all of these view > callable conventions, however, you can use the decorator= argument to > view_config. The point of the decorator= argument to view_config is to > provide genericness by accepting a decorator that can use a single > common call signature for a decorator ("(context, request)"). So you > can use the following decorator: > > def adecorator(viewcallable): > def inner(context, request): > print request.url > return viewcallable(context, request) > return inner > > .. against this kind of view configuration ... > > class AView(object): > def __init__(self, request): > self.request = request > > @view_config(decorator=adecorator) > def aview(self): > return Response('OK') > > .. or this kind ... > > @view_config(decorator=adecorator) > def aview(request): > return Response('OK') > > ... or this kind ... > > @view_config(decorator=adecorator) > def aview(context, request): > return Response('OK') > > ... or this kind ... > > @view_config(decorator=adecorator) > class AView(object): > def __init__(self, request): > self.request = request > > def __call__(self): > return Response('OK') > > ... or this kind ... > > class AView(object): > def __init__(self, context, request): > self.context = context > self.request = request > > @view_config(decorator=adecorator) > def aview(self): > return Response('OK') > > You get the point. The *same decorator* will work against any view > callable you define, even though the place it gets used differs: > against a method of a class, against a class object, against a function > object, and the associated callable may have different arguments. It > will still work in all scenarios. > > Since a decorator is just a callable that returns a callable, whether > you use the package you linked to or not to produce one is irrelevant. > Even the "@" syntax is just sugar. Instead of: > > @decorator1 > @decorator2 > def func(): > ... > > it could just be: > > def func(): > ... > > func = decorator2(decorator1(func)) > > If you're decorating functions or methods that you don't know the > argument list for, just make the decorator accept *arg, **kw and pass > those along to the wrapped function from your wrapper function defined > inside the decorator. That will work for any sort of wrapped function, > even those for a view callable. > > If you mean you want to create some sort of omniscient decorator that > can be used for both a view callable *and any other kind of function*, > but which in both cases requires a request to.. do something.., then, > yes, you could use get_current_request inside the decorator logic. It'd > be insane to try to define such a decorator, when you could just create > one that expected the decorated function to supply the (context, > request) signature, but you could do it. > > If this all boils down to "why dont you support a sequence rather than a > single function as a valid decorator= argument" because you need to mix > and match logic in your decorators, please either submit some code that > makes it so or use the recipe for chained decorators. > > - C > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/fhyzewf5dfkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
