On Monday 29 December 2003 17:19, Graham Fawcett wrote:
> Hi Oscar. I'm still here, just recovering slowly from having too much
> Christmas turkey. ;-)

A suggestion: ( not for calories afraid people)
Here, on St. Stephen day, we use to cook canelons (caneloni?) with excess meat
from Christmas turkey. Too late?

> 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.

Yes, Application is more precise.
'Model' and 'logic' are others. But don't feel specially proud of any of them.

> > 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).
>
Agree.

> > 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.
>
Completely agree. This was also my idea behind.
.Describe application via class attributes.
.Have the chance to make initialization via Context class constructor.

In your case, calling and empty argument list constructor, could avoid define
any constructor at all. And request is always available via get_request().

> 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.

A good wish while looking at Saturn. ;-)


Salut.

Oscar Rambla

-May be next year-.
 Extracted from 'Send in the clowns' by S. Sondheim.