Re: Providing data to a function using a decorator

Johan Hartzenberg <[email protected]> Sun, 6 Nov 2016 23:20:12 -0800 (PST)
Newsgroups gmane.comp.python.cherrypy
Message-ID <[email protected]>
Thank you.  This is already on my Todo list but I'm prioritising it now.

I ended up just storing the results from decorators in 
cherrypy.request.myvar for use by the wrapped function, but now I need the 
reverse:  I need access to something in the application class from inside a 
decorator (My DB connection pool in this case).  How do I pass "self" to 
the decorator?  I am almost afraid to ask as I suspect the answer will be 
LOOK AT TOOLS again!!  So I will do that today....

On Monday, November 7, 2016 at 8:02:19 AM UTC+2, Joseph Tate wrote:
>
> Not decorators, Tools.
>
> Tools do not need to be turned on and off to do unit testing, they happen 
> outside the handler context. Unit testing becomes super simple: set up 
> dummy request and response objects, and call the instantiated method with 
> the proper arguments. Check the response.
>
> Tools have a lot more flexibility than decorators. There are some six or 
> seven registration points for tools. Pre-handler tools can register post 
> handler tools in real time.
>
> Tools can be configured in CONFIG, not in code.
>
> Take a look at the built in tools, and the stuff posted on 
> http://tools.cherrypy.org/wiki/TitleIndex for inspiration.
>
> On Sat, Nov 5, 2016 at 4:23 PM Johan Hartzenberg <[email protected] 
> <javascript:>> wrote:
>
>> Many of my route handlers go through a sequence of similar steps, eg
>>
>> def handler_x(self, **kwargs):
>>   #Check Authentication
>>   ...  
>>   #Validate Input
>>   ...
>>   #Check Authorization
>>   ....
>>   #Perform Database Query/Update
>>   ...
>>   #Format result into response
>>   return response
>>
>> It would seem that this sequence lends itself to being put into 
>> decorators.  I have to some extent put these into functions already, but I 
>> still end up with a lot of code like
>>
>>
>> def handler_x(self, **kwargs):
>>   ...
>>   try:
>>     dbcursor = ....
>>   except ..
>>
>>   Etc etc for every step of the handler
>>
>>   The format of each of these "decorators" appears to be
>>   try to get some value (a user-name, a db connection, etc)
>>   Check whether it was sucesful
>>   Return a response if not
>>   Use the response in the next step
>>
>> So basically imagine
>>
>> @dict_to_json
>> @check_authentication (this sets username)
>> @check_valid_input
>> @get a database connection (this uses username, and sets a cursor)
>> @check authorization (this uses username and cursor)
>> def handler_x(self, **kwargs):
>>   use username and db_cursor here
>>   return a result
>>
>> So the question is how do I get the results from one decorator to be 
>> accessible to the next.
>>
>> My first thought would be to build on cherrypy.request ... set the 
>> results as properties on there, which can then be accessed by subsequent 
>> functions/decorators... But maybe there is another way that I am not aware 
>> of...
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "cherrypy-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to cherrypy-user...-/[email protected] <javascript:>.
>> To post to this group, send email to cherryp...-/[email protected] 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/cherrypy-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To post to this group, send email to cherrypy-users-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
Visit this group at https://groups.google.com/group/cherrypy-users.
For more options, visit https://groups.google.com/d/optout.