Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@sundn.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Environment Revamping
Date: Fri, 19 Oct 2001 16:56:12 +0200
Message-ID: <GMEBIBHGAOFGJCDPJANDOEGPCPAA.cziegeler@sundn.de>
MIME-Version: 1.0
In-Reply-To: <3BD0217D.F0A4F369@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

> Berin Loritsch wrote:
> 
> Carsten Ziegeler wrote:
> > 
> 
> > > public interface SystemContext extends
> > > org.apache.avalon.framework.context.Context {
> > >     Source resolve(String uri);
> > >     org.apache.cocoon.environment.Context getEnvironmentContext();
> > >     Object get(Object key); // from Avalon context
> > > }
> > >
> > > This removes the need for the SourceResolver interface to be
> > > exposed or passed
> > > as an argument to Components.  Components that do not need it or
> > > use it will
> > > have access to a simpler API.
> > >
> > The intention of this interface is very good, I like it, but
> > I see one (more technical) problem here: the resolve() method
> > is Environment or Request dependant. This means, if a component
> > (e.g. the store) is contextualized at startup and gets the
> > SystemContext, the resolving of resources must be done
> > with the current environment in mind which might result in
> > different resources.
> > This resolving with respect to the current environment is
> > of course necessary for all sitemap components (generators
> > etc).
> > If we get this working: +1
> 
> 
> Ok, with that clarification, the resolve method would move to 
> RequestContext.
> 
> > What do you mean with the org.apache.cocoon.environment.Context
> > object? Is this the RequestContext mentioned below?
> 
> No, that is the equivalent of the ServletContext.  It is global in scope,
> and only a few components _really_ need it.  If you need it, extend
> Contextualizable, and cast the Context to SystemContext.
> 
Sorry, I was not very clear here:
I meant the object returned getEnvironmentContext().


> > > Lastly, this will also open up API optimizations in that we can
> > > simplify the
> > > signatures to setUp(RequestContext context, String source,
> > > Parameters params);
> > > If there is some new interface that needs to be supplied to 
> the sitemap
> > > components, it will be done through the RequestContext or
> > > SystemContext objects
> > > as is appropriate.
> > >
> > +1
> > 
> > What about the Interface Cookie you mentioned above? I personally would
> > like to clean up Request/Response interfaces.
> > There are certainly Environments which do not use Cookies and for
> > example don't know anything about headers. So I would like to separate
> > them from the Request/Response so that one could test if the
> > current environment supports this feature or not.
> 
> Hmm.  If an environment doesn't support a feature, then it should
> ignore it--in the case of headers.  As to the Cookies--Cookies are
> persistent client storage.  Persistent in the fact that they can last
> between sessions--not that they live forever (although sometimes it
> seems like it).
> 
> In the cases where Cookies are not supported, we should follow the
> standards of how Servlets handle the case when Cookies are turned
> off.  If there is no standard, we can throw a 
> UnsupportedOperationException
> or something similar.  It would have to extend Runtime exception
> though.
> 
> If you have specific API cleanups for Request/Response, we can go through
> them as well.  I was wanting to simplify the UI as much as possible
> for the HEAD branch.
> 
Yes, that's great: I would like to have the minimum methods on those
interfaces as possible. That's why I thought about "outsourcing"
for example the Header stuff.

Headers are optional. An environment can of course ignore them, but
if a user of a request object calls setHeader() etc. it expects
that the header is really set. 
If it can beforehand test, if headers are supported, that's for
me a cleaner solution. This test could either be done by separate
marker-like interfaces or by "supportsHeaders()" methods.
But - as Ovidiu stated recently - we should keep in mind to support
in any way most methods/features the servlet environment offers.
I will try to come up next week with a proposal for Request
and Response objects.

Carsten

> 
> > By the way: About what timeframe and version are we talking here?
> 
> 
> These are changes to HEAD.  It should be done sooner than later so we
> don't forget about them.  But it is good for Cocoon 2.1.  The arrangement
> allows use to simply deprecate the unused methods and point users to
> the real implementation.  The deprecated methods should live for at least
> a year--that way as projects naturally upgrade, they can move to the
> new API.  With the LogKit, we found that 5.5 months was not long enough
> for projects to migrate.
> 
> P.S. This should not delay Cocoon 2.0 final.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org