Jason E. Sibre wrote:
> I typically have a package that corresponds to the application, and
> it contains two modules/sub-packages of interest for this discussion:
>  api, and web.  "web" is the quixote UI stuff, and "api" is a module
> defining a class that, when it's instantiated (with proper
> configuration information) represents a 'live' application, and
> provides methods and attributes for interacting with that application
>  (the UI code only interacts with Quixote and the API).  Within the
> api module, there is an attribute called 'configuration' which I
> initialize to contain all the info the class will need when it is
> instantiated.  The driver script initializes the contents of
> application.api.configuration after importing, but before calling the
>  Publisher.publish_fcgi().

That's kind of how I've done it as well.

> All things considered, I'd probably like (and use) this context
> attribute you've introduced, as it provides a good place for storing
> not just configuration info, but also things like my 'live'
> application instance.

Yes, that's what I had in mind: use an object that implements the API of
your back-end application.



One drawback to my proposal is that we would lose the documentational
role played by imports. Compare:

     from api import users

     def _q_lookup(request, name):
         user = users.get_user(name)
         ...

with the 'context style':

     def _q_lookup(request, name):
         user = request.context.get_user(name)


...from a maintenance perspective. It is clear what the second version
means, but I don't know where 'request.context.users' is defined. Not
immediately, anyway: I would need to read the driver script at least
once to determine where the context's class was defined.



That's not enough to dissuade me from using the method. At the risk of
overstating my case, it might even be a good thing to prod/encourage our
fictional maintainer to go study the context first. In this light,
the 'context approach' takes a single class defintion and says, "this is
the well-documented entrance to the back-end" rather than "here are an
assorted collection of back-end libraries" (which is what a number of my
Quixote apps look like, probably not for the best...).

Thanks for the feedback, Jason.

-- Graham