Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BD0217D.F0A4F369@apache.org>
Date: Fri, 19 Oct 2001 08:50:05 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Environment Revamping
References: <GMEBIBHGAOFGJCDPJANDEEFOCPAA.cziegeler@sundn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.

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


> 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