cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Environment Revamping
Date Fri, 26 Oct 2001 12:37:53 GMT
giacomo wrote:
> 
> On Thu, 18 Oct 2001, Berin Loritsch wrote:
> 
> Cool analysis and explanation of the moves to take.
> 
> Do you have an idea of how much time it needs to do the move?
> Did you indent it to go into 2.0 or 2.1?
> 
> Anyway you have my +1 for it.

I intend it for 2.1, and it will take a few hours to accomplish.

> 
> Giacomo
> 
> > Currently, the Environment system has grown to provide an abstraction
> > layer so that Cocoon logic can function equally well depending on whatever
> > the environment is.  This is a good thing, and in my opinion very necessary.
> > However, what we have in our API can get confusing both for Cocoon app
> > developers, and for environment adaptor providers.
> >
> > Because Cocoon began life as a Servlet, the environment is heavily slanted
> > in that direction.  While I do not want to reinvent the wheel that the
> > servlet vendors have created, we can simplify our API so that app developers
> > have an easier time.  Currently, the Environment consists of the following
> > interfaces:
> >
> > * Environment
> > * Context
> > * Cookie
> > * Redirector
> > * Request
> > * Response
> > * Session
> > * Source
> > * SourceResolver
> >
> > In addition to this we have the Avalon Context that we are using within
> > the rest of the API for Cocoon system properties.  Some of this is a bit
> > much, and can be merged, and we can have a simpler API because of it.
> > Granted that this would require deprecating some pieces in the HEAD
> > branch of CVS, but I think we would be better for it in the long run.
> > First, we have to consider what each piece is used for.
> >
> > INSTALLATION SPECIFIC API
> > org.apache.avalon.framework.context.Context
> > org.apache.cocoon.environment.Context
> > SourceResolver
> > Source
> >
> > SESSION SPECIFIC API
> > Session
> >
> > REQUEST SPECIFIC API
> > Redirector
> > Request
> > Response
> > Map (ObjectModel)
> >
> > PERSISTENT CLIENT STORAGE
> > Cookie
> >
> >
> > In addition to all this, the ObjectModel is simply a Map that allows access
> > to all of the APIs as we need them.  It is clear that too many indirections
> > (i.e. Maps) create a more cluttered API.  What should we do then?  Clearly
> > there are two major categories of Context.  There is the system context which
> > provides meta information about the installation.  Then there is the request
> > specific context which allows us to pass information between stages, and
> > access the session and client storage mechanisms.
> >
> > In order to simplify, I believe that there should be 2 Context objects to
> > worry about: SystemContext and RequestContext.  The SystemContext object
> > would extend the AvalonContext--and be passed to any Contextualizable
> > Component.  So what would this look like:
> >
> > 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 other Context woudl be the RequestContext.  That API would be like this:
> >
> > public interface RequestContext extends Map {
> >     Request getRequest();
> >     Session getSession();
> >     Session getSession(boolean forceNew);
> >     Response getResponse();
> >     void redirect(String uri); // throws IllegalStateException if called after generator
setup.
> >     Object get(Object key); // from Map
> >     void put(Object key, Object value); // from Map
> > }
> >
> > This makes the RequestContext compatible with ObjectModel as it stands now--
> > not forcing any MAJOR changes to the API.  It also removes the need of exposing
> > the Redirector interface to the clients as a passed argument.  While it may
> > seem tempting to do so, most developers will get the clue very quickly that
> > it can only be done from the SetUp method.  This will expose it to be used to
> > generators and transformers alike, but the distinct difference is that the
> > setup and generate commands are separate.
> >
> > This also simplifies client code--and the get/put methods in the RequestContext,
> > but it also minimizes the overhead involved in looking up the specific environment
> > interfaces from a generic Map.
> >
> > You'll notice that the Environment interface is missing.  That is because the
> > Environment interface has been identified as the contract between the sitemap
> > and the environment that Cocoon is living in.
> >
> > 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.
> >
> > ---------------------------------------------------------------------
> > 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

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


Mime
View raw message