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 20:00:35 GMT
Ricardo Rocha wrote:
> 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

Also agreed.

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

I think this is absolutely the case.

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

Yes, agreed.

Generators, Readers and Transformers have the same setup() method
signature. So we need a name for this abstraction (and a package place
to put it in).

Matchers and Selectors don't have a setup method because they get what
they need at their match/select method to make it possible to keep those
objects thread save.

Serializer and Reader only need to have access to the OutputStream. Here
we need a name and a place for this abstraction, too.

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

Absolutely. I'm more that happy to eliminate those casts.

> 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

This is also a relict which Casten Ziegeler has pointed out in an mail

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

The mime-type is defined in the sitemap at the <map:serializer> element
(as the default mime-type) and can also be specified at the
<map:serialize> element (to overwrite it in case a serializer can handle
several mime-types, but I don't know if this is feasible). Because of
this the ResourcePipeline exactly knows what mime-type the current
Serializer should use and can set it without having the Serializer to
ask for, right? And don't forget the Readers. They behave exactly like
Serializers in this case. But also here the ResourcePipeline knows
exactly what has been mentiond in the sitemap.

> 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?]


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