Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: ricardo@ricardo
Message-ID: <3989C4EE.300C20BD@apache.org>
Date: Thu, 03 Aug 2000 14:15:58 -0500
From: Ricardo Rocha <ricardo@apache.org>
Organization: Plenix
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Change of the Environment abstraction
References: <398966DA.46FFAEBE@pwr.ch> <39897A4F.8C756AF5@apache.org>
 <39898CA2.A0D9038C@pwr.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Reality check: so far, we've agreed that:

1) SitemapComponents, in general, must _not_ have access to the
   Environment object as such, but rather to its object model and/or
   to its output stream. Only the Sitemap[Manager] should have
   direct access to the environment. This is so because we don't
   want to give these components access to potentially harmful
   (or simply unnecessary) objects, such as the [servlet] output
   stream

2) Some SitemapComponents (Generator, Matcher, Reader, Selector,
   Transformer) need access to the environment's object model
   only

3) Serializers need access to the environment's output stream
   only

4) Readers need access to both the object model and the output
   stream

Is this correct?

Giacomo wrote:
> 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?

Probably. Their former [apparent?] commonality arose from the
belief that all of them needed uniform access to the environment
object. If, as stated above, this is not the case, itmay be
better to specify separate setup methods for each one.

I'd like to double-check this, though: in specifying separate
setup methods we'd probably identify a few common patterns
(access to the object model, the output stream or both, common
semantics for the "source" and "parameter" arguments, etc) that
call for a common abstraction... what do you think?


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

Right


One more point:

The Environment interface was extended to include a setContentType()
method.

The only context where the Environment's setContentType() method is
used is in the ResourcePipeline process() method (to set the reader
or serializer mime type). 

Currently, however, all serializers cast their environment to
HttpEnvironment to access its [servlet] response object and use it to
set the content type (bad!) This is probably a fossil from the time
when setContentType() hadn't been added to the Environment interface
and may have become unnecessary now that the ResourcePipeline takes
care of handling it. Is this correct?

What do you think about the following?

1) Probably the _only_ context in which content type should be set
   is inside the ResourcePipeline process() method
2) Serializers should _not_ be responsible for setting content type
   themselves
3) Instead (and given that every serializer has one and only one
   content type), the Serializer interface should expose a
   getContentType() method that is invoked by the ResourcePipeline
   process() method and then passed to the Environment object for
   actual mime type setting.

This would relieve serializers from having to interact (mess?) with
the environment or its object model while delegating/centralizing
content type handling to the only object that really "knows" about
it: the environment.

[Question: what whould "content type" mean for the OfflineEnvironment,
for instance?]