cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject RE: [RT] Environment Revamping
Date Fri, 19 Oct 2001 11:44:49 GMT
+1 from me.

--- "Morrison, John" <John.Morrison@uk.experian.com> wrote:
> Looks good: +1
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, 18 October 2001 4:41 pm
> > To: cocoon-dev@xml.apache.org
> > Subject: [RT] Environment Revamping
> > 
> > 
> > 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
> > 
> 
> 
> =======================================================================
> Information in this email and any attachments are confidential, and may
> not be copied or used by anyone other than the addressee, nor disclosed
> to any third party without our permission.  There is no intention to
> create any legally binding contract or other commitment through the use
> of this email.
> 
> Experian Limited (registration number 653331).  
> Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

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


Mime
View raw message