cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Change of the Environment abstraction
Date Fri, 04 Aug 2000 19:13:48 GMT
Giacomo Pati wrote:
> 
> 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
> 
> Agreed.
> 
> > 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
> 
> Yup.
> 
> > 4) Readers need access to both the object model and the output
> >    stream
> 
> Yeah!
> 
> > 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).

I propose that the Generator, Reader and Transformer Interface extend
the following Interface (as a replacement for the SitemapComponent
Interface):

  package org.apache.cocoon.sitemap;
  public interface SitemapModelComponent extends Component {
    public void setup(EntityResolver resolver, Dictionary objectModel, 
                      String src, Parameters par)
    throws ProcessingException, SAXException, IOException;
  }

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

I propose that the Matcher and Selector Interface extend only the
Component Interface (not the SitemapComponent).

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

I propose that the Serializer and Reader Interface extend the following
Interface (as a replacement for the SitemapComponent Interface):

  package org.apache.cocoon.sitemap;
  public interface SitemapOutputComponent extends Component {
    public void setOutputStream(OutputStream out) throws IOException;
  }

Giacomo

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

Mime
View raw message