durusmail: quixote-users: Re: Request contexts
Request contexts
2003-12-11
Re: Request contexts
2003-12-11
2003-12-11
2003-12-12
2003-12-12
2003-12-13
2003-12-13
2003-12-16
2003-12-16
2003-12-16
2003-12-16
2003-12-15
Re: Request contexts
2003-12-16
2003-12-16
2003-12-24
2003-12-30
2003-12-31
Re: Request contexts
Graham Fawcett
2003-12-16
Dave Kuhlman wrote:

>>>In an earlier message Graham said:
>>>
>>>>For example, one could create a database connection as a context
>>>>object, set it in the publisher, and thus make it available to
>>>>all requests that need it.
>
> OK.  I'm following this suggestion (Graham's I think).  What I've
> done is to sub-class the Publisher class, and (1) in the
> constructor of my sub-class I create a DB connection and (2) I
> override the Publisher's start_request method so that it stuffs the
> connection into the request object before each request is handled.
> Is this an accepted Quixote-ism?
>

[sample code snipped]

Not sure if it's an accepted Quixote-ism, but I'm sure many of us have done
something similar (I know I have).

This was part of the motivation behind my original proposal. A "context object"
would provide a single entry point to the back-end application (db connection,
logic, whatever). And it would encourage "one way to do it", where "it" is
passing non-UI state/logic into the UI code.

For example, we wouldn't need to (or want to) subclass Publisher, when we could
just call a well-defined publisher.set_context() method. Similarly we wouldn't
need to/want to import all kinds of back-end stuff into our PTL files, because
the request.context already has everything we need.

But other than that, the only difference between your approach and mine would
be the name of the attribute (request.dbconnection or request.context).

[snipping the rest, answered by wiser heads]

-- G





reply