cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: What happened to Roles.COCOON?
Date Fri, 16 Feb 2001 15:35:39 GMT
> Giacomo Pati wrote:
> Well, I think the right approach to this is to change the way
> FileGenerator,
> ServerPageGenerator and TraxTransformer handle the value of their source
> attribute. IMHO they should use the URLFactory (which needs to be expanded
> in
> this way) with the source as one parameter (the URL) and a second 
> parameter
> which is a ContentHandler (maybe more parameters for the LexicalHandler).
> In
> the case of an stream based protocol (file, resource, context) the
> URLFactory
> should use an parser instance to stream the SAX events to the passed
> Handlers. In the case of a cocoon protocol the URLFactory should 
> be able to
> pass the URL directly (using the same Environment but a different
> requestURI)
> to a Component that can produce a pipeline using a sitemap engine. Thus
> this
> needs changes to the sitemap engine as well ie. splitting the process
> method
> up into one that does the core work to produce a ResourcePipeline object
> (that's what the main part of the process method does today) and one that
> calls the former method and kicks the process method of the assembled
> ResourcePipeline object.
> 
> In the case of processing an URL of a cocoon protocol the "inner" method
> (not
> the normal process method) of the sitemap engine must be called to get an
> assembled ResourcePipeline object which can be used to pipe the SAX events
> into the ContentHandler passed to the URLFactory.
> 
Yes, a cocoon protocol for the URLFactory would also solve my problem!
Why can't this component that produces the pipeline not simply use the already
instantiated cocoon object from the current process?

> This is my research on how subpipeline could work using a special 
> protocol,
> so far.
> 
> Giacomo

Carsten


Mime
View raw message