cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: AW: [C2]: What happened to Roles.COCOON?
Date Fri, 16 Feb 2001 15:23:33 GMT
Carsten Ziegeler wrote:
> > Giacomo Pati wrote:
> >
> > Carsten Ziegeler wrote:
> > > Hi,
> > >
> > > after updating to the latest CVS the Roles.COCOON has disappeared!
> >
> > Yes, read the mail from berin from last night .
> Hmm, ok it seems that my mail account is still not working correct. I
> didn't get any mail from berin. I will check the mail archive then.
> > > Was this removing intentionally? And why?
> >
> > Because it doesn't offer any services and it never really was a
> > Component. It
> > was made so initially and was keeps so for a too long time.
> >
> > > How can I get the Cocoon instance now? A simple
> > > ComponentManger.lookup(Roles.COCOON) does of course not work anymore.
> >
> > Why do you need a Cocoon instance? There is nothing you should
> > need to mess
> > around with it.
> OK, you're right, there should be no need....but....
> I just it for performance reasons. I wrote a kind of IncludeTransformer
> which includes resources from the sitemap. Instead of getting them using a
> url and thus sending an http request from inside the server, my *trick* was
> to create an own environment for this request, parse it to the Cocoon
> instance to process it. I know this might not be the way it should, but for
> my project its the only way it works... Now I have to invent another
> "dirty" trick...

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.

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


> Carsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

View raw message