Oscar Rambla wrote:
> On Tuesday 16 December 2003 16:42, Oscar Rambla wrote:
>
>>On Monday 15 December 2003 19:13, Graham Fawcett wrote:
>>
>>>Personally, I like the idea of passing the applications/packages/api's to
>>>the Publisher. A drawback of your approach is that it requires a
>>>SessionPublisher in order to work, and thus it is a bit less general.
>>
>>It's begining to like me, too.
>>I think,  Publisher context is convenient.
>>
>>In my case, this could help bring up user session and other off session
>>functions.
>>
>>Later, session and application (and others) while traversing could
>>update/upgrade request.context.
>>
>>Your comments have made improve my understanding. (Hope!)
>>
>
>
> Continue.. (Are you still there?)

Hi Oscar. I'm still here, just recovering slowly from having too much Christmas
turkey. ;-)

>
> I've been working a bit (slowly) on your proposal.
>
> One thing worries me about it is that someone (me, for example) could be
> tempted to use request.context for storing things he didn't expect to survive
> publisher's live long.


I suppose that this could happen. Perhaps it's a naming problem; "context" is
rather generic. That's why I chose it, really; I thought it might be more
acceptable to the larger Quixote user group. My initial intention was to call
it request.application, since my personal motivation was to provide an object
that interfaced with the back-end application. Perhaps that would be a better
naming.

If I recall my Java Servlet API, I think they use the term 'Application' to
refer to a similar concept. Other Web frameworks have used similar concepts;
the Enhydra framework (another Java-based system) comes to mind.

>
> Currently , i'm woking on this variant from your patch and Dave Kuhlman's
> example. (In fact, a SessionPublisher version of this). Don't pretend it to
> be better than yours, only to ilustrate my point of view.
>
> class ContextPublisher( Publisher ):
>
>     def __init__ (self, root_namespace,  context_class, config=None):
>         Publisher.__init__(self, root_namespace, config)
>
>         self._context_class = context_class
>
>     def set_context(self, context_class):
>         self._context_class = context_class
>
>     def start_request(self, request):
>         # start_request seems to be made for this kind of things
>         request.context = self._context_class()
>
>         # nobody knows if sometime it won't be empty ;-)
>         Publisher.start_request(self, request)
>
> # class ContextPublisher
>
> Advantages:
> .Make context attributes available application wide. ( Your point).
> .Keeps integrity of initial context.


Yes, these are both strengths in my opinion. I'd also add

- improves separation of logic and UI modules by removing explicit imports.

which is a strength of both approaches (though some might argue it isn't a
strength at all).

>
> Known limitations:
> .Involves subclassing Publisher. (What you try to avoid).
> .Forces Context to be a class with an empty argument list constructor.
>

I don't have a problem with constructing a Context object every time a request
is started. In some cases, this might have some benefits, since it could let an
application designer take advantage of the request lifecycle. In other words,
there may be actions that the application should undertake when a request is
initialized; these could be handled in the Context constructor. Similarly, some
actions might be important when the request is complete; these could be handled
in a Context destructor. (Perhaps the request object could be passed in to the
Context constructor; that might let the constructor access information that
might be useful in its construction?)

Personally, I'd probably just construct a proxy to another, longer lived
object, which I would store as a class attribute of my Context class. The
benefit to me is to have a single long-lived object that could maintain (for
example) database connection pools and other long-term state. Also, that
long-lived object would give the API to the back-end logic of my application.
Lifecycle events aren't important to me right now, but it would be nice to have
the choice.

Your ideas and mine are compatible, I think, Oscar. At the end of the day, I
would just like to see an idea like ours become part of the Quixote standard.
Although not all application designers will like the idea of a context object
that acts as a gateway to a back-end application (or applications), I think it
is an appropriate separation of concerns. Of course, it will never be
*required* that all developers use the context approach, but having it built
into the Publisher class will make it available for those of us that would use
it.


Best wishes to you and all Quixotistas in the holiday season,

-- Graham