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.