cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Change of the Environment abstraction
Date Thu, 03 Aug 2000 15:15:46 GMT
Ricardo Rocha wrote:
> Giacomo Pati wrote:
> > 1. The output stream is a property of the calling environment and should
> >    be made available only through it (as opposed to a separate argument
> >    as seen in the current implementation of Cocoon.process(),
> >    SitemapManager.invoke() or sitemapHandler.process()).
> > . . .<skip/>
> > 3. Every Environment has an associated object model expressed as a
> >    collection of named objects whose names and types vary from
> >    environment to environment. Instead of defining environment-specific
> >    get[Object]() methods, it's more general to define a higher-level
> >    Environment.getObjectModel() method that returns a Dictionary of
> >    objects making up the model.
> > . . .<skip/>
> >    We add:
> >      public Dictionary getObjectModel();
> >    to the Environment interface.
> > . . .<skip/>
> Currently, Generators, Transformers, Serializers and Readers are all
> passed the Environment object as argument to their setup/generate
> methods.

This is because of the SitemapComponent Interface definition which all
those objects (had to) implement.

> It appears to me that Generators and Transformers should NOT have
> access to the Environment as a whole but _only_ to its object model.

Would make sense to me.

> If we give these processors access to the environment, they could (for
> instance) manipulate the output stream directly, thus defeating one of
> the
> purposes the Environment abstraction was conceived for in the first
> place.


> What these classes really need, I think, is access to the Environment's
> _object model_. For example: In the HttpEnvironment, Generators (and XSP
> pages) need access to servlet objects like "request", "context", etc.
> Transformers may also need access to the HttpRequest...

As well as Selectors and Matchers.

> Serializers (and Readers), on the other hand, need access to the
> Environments's output stream. I can't see now why these processor types
> should need access to the object model, though it may well be the case
> (those of you who see a need for this, please enlighten me).

Readers work like a Generator and thus may need to have access to the
object model.

> Thus, I think Serializers and Readers should be passed the Environment's
> output stream only, instead of the Environment object as such (or its
> object model).

All this means, that we must deprecate the SitemapComponent interface at
all and specify the setup methods directly into the
Generator/Transformer/Serializer/Reader interfaces, right?

The Environment object also server as the EntityResolver to all the
components and the sitemap itself cannot take the resonsability to
resolve every possible resource (component configurations can contain
resources the sitemap has no idea of).


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

View raw message