durusmail: quixote-users: 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
Request contexts
Graham Fawcett
2003-12-11
I'just curious whether anyone would be interested in the following
patch. It allows one to set a "context object" while configuring a
Publisher; this context object is then passed into each request's namespace.

There doesn't seem to be a direct way to connect a Quixote application
to a back-end interface or a database connection. By "direct" I really
mean "configurable", in the sense that you don't have to hunt through
the application source to find where the database connection was
initialized (for example). And of course, different folks implement such
things differently...

(By "direct" I also mean "cleanly separated" in that there ought to be
(IMO) a minimum of import dependency between the UI modules and the
logic modules. Quixote seems to require that UI modules import code
(from a business-logic module) in order to gain a reference to the
back-end; this is a early-and-static binding that could be avoided.)

My suggestion is to allow a "context object" to be added to the
Publisher in the handler script, while it's being configured. This
object would then be available to each request via the request.context
attribute.

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. (More likely I would use a facade to my back-end app, rather
than a raw db connection, but you could use whatever worked for you.)

The patch I've provided adds set_context() and get_context() methods to
the Publisher, and also a line to set the context attribute on a request
during a try_publish() call. There would be no side-effects for existing
apps, since the default context is None.

It seems like a clean and simple way to wire the front and back ends
together at a single configurable point: the handler script.

(I suppose a rigorous implementation might expect a context object to
have a "shutdown()" method or some such thing in order to handle a clean
break from the backend when closing down the app. But I'm not quite sure
where I'd put the code to call such a shutdown method.)

Thoughts?

-- Graham



--- C:\projects\Quixote-0.7a3\publish.py        Wed Dec 03 18:30:30 2003
+++ publish.py  Thu Dec 11 13:43:47 2003
@@ -134,6 +134,7 @@
              self.set_config(config)

          self._request = None
+        self._context = None

      def configure (self, **kwargs):
          self.config.set_from_dict(kwargs)
@@ -424,6 +425,27 @@
          """
          return self.namespace_stack

+
+    def set_context(self, context):
+        """set_context(context : context_object) -> None
+
+        Sets a 'context object' for the publisher. This object will
+        be made available to every request via the request.context
+        attribute. It can be used, for example, to pass in a reference
+        to a back-end system, such as a database connection.
+        Subclasses are welcome to override this method, as well as the
+        get_context() method.
+        """
+        self._context = context
+
+    def get_context(self):
+        """get_context() -> context_object
+
+        Return the publisher's context object. See set_context().
+        """
+        return self._context
+
+
      def try_publish (self, request, path):
          """try_publish(request : HTTPRequest, path : string) -> string

@@ -432,6 +454,8 @@
          the output is returned.  Exceptions are handled by the caller.
          """

+        request.context = self.get_context()
+
          self.start_request(request)

          # Initialize the publisher's namespace_stack



reply