Currently the handler classes are instantiated for every single request, so it
should be safe to store request specific information inside the handler
instance, see function handle_class()
<https://github.com/webpy/webpy/blob/master/web/application.py#L431>.
However: a web.py dev once said that this behavior should be considered an
internal implementation detail of web.py and might change in the future. I
guess if you want to be on the safe side you would have to encapsulate your
logic into a separate class which is then instantiated and used by the GET/POST
methods in the handler instance. Like so:
class MyInternalHandler(object):
"""internal handler which can be used to store
information over the lifetime of a request."""
def do_get(self):
self.state = 'something'
self.do_something()
return 'something'
class MyExternalHandler(object):
"""external handler which is specified in the
url mapping and is used by web.py to handle
the request."""
def GET(self):
h = MyInternalHandler()
return h.do_get()
Personally I'd consider that to be a bit disproportionate, but still.
Ole.
Am 02.07.2013 um 09:42 schrieb john martin:
> my understanding is that when a request is made to a web.py app, the GET or
> POST method of the python class that maps to the requested URL is invoked.
>
> for instance, in the "hello world" example
> (http://webpy.org/cookbook/helloworld), any GET request will have its
> response rendered by the GET method of an instance of the hello class.
>
> my question is: does web.py re-instantiate the appropriate page class for
> each request, or does it re-use instances it's already created? i.e., would
> a new instance of the hello class be created for each request in the above
> example, or would instances of hello that've been created get re-used?
>
> the reason i'm wondering is that i'm trying to figure out whether i
> can/should store request specific information (e.g., a session object) on the
> page class instance. i wasn't sure, so i don't do that at the moment (e.g.,
> i have a common base page class, and it invokes a page rendering method that
> each of its subclasses implements, and it currently passes in the session
> object used by that render method, but it feels like it'd be cleaner to have
> that session object be an instance variable if possible, i.e. i'd refer to it
> as self.session_obj instead of passing session_obj into my render method each
> time it's invoked).
>
> maybe another slightly less wordy way of asking the above question is this:
> in the "hello world" example, could the GET method store some
> request-specific info on its self parameter without interfering with the self
> parameter that's passed by calls to that GET method when other requests are
> made?
>
> if whoever's responding could point me to the part of the web.py codebase
> that actually executes this behavior, that'd be great too.
>
> thanks in advance!
>
> -john
>
> --
> You received this message because you are subscribed to the Google Groups
> "web.py" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/webpy.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Ole Trenner
<[email protected]>
--
You received this message because you are subscribed to the Google Groups
"web.py" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.