[C2]: What happened to Roles.COCOON?

[Carsten Ziegeler <cz...@sundn.de>]

Hi,

after updating to the latest CVS the Roles.COCOON has disappeared!

Was this removing intentionally? And why? 

How can I get the Cocoon instance now? A simple ComponentManger.lookup(Roles.COCOON) does of course not work anymore.

Carsten 

Re: AW: [C2]: What happened to Roles.COCOON?

[Giacomo Pati <gi...@apache.org>]

Carsten Ziegeler wrote:
> > 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!

To achieve this you need a second execution path to process a request (one 
that returns the assembled ResourcePipeline object instead of processing that 
as well).

> Why can't this component that produces the pipeline not simply use the
> already instantiated cocoon object from the current process?

I think the Cocoon object is not the right one. I think the sitemap.Manager 
is the one you are looking for, right? and there should the second execution 
path for subpipelines start.

Giacomo

AW: [C2]: What happened to Roles.COCOON?

[Carsten Ziegeler <cz...@sundn.de>]

> 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

Re: AW: [C2]: What happened to Roles.COCOON?

[Giacomo Pati <gi...@apache.org>]

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.

Giacomo

>
> Carsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Re: AW: [C2]: What happened to Roles.COCOON?

[Paul Russell <pa...@luminas.co.uk>]

* Berin Loritsch (bloritsch@apache.org) wrote :
> Ok, but what we the end product, an Aggregation system?
> I think there is the beginnings of one with the
> FragmentExtractorGenerator that will make recursive
> sitemap calls for you.

Hmm. That's not quite what it does -- it takes SAX events from a
document, and stashes them for later retrival from another pipeline.
Common use being to extract inline SVG documents from xhtml streams.
(roll on proper SVG and namespace support in browsers).

I'm going to try and post a proposal for content aggregation for voting
sometime over this weekend. I would have done it earlier, but my Copious
Free Time has been taken up with other things of late.

P.

-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk

Re: AW: [C2]: What happened to Roles.COCOON?

[Berin Loritsch <bl...@apache.org>]

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

Ok, but what we the end product, an Aggregation system?
I think there is the beginnings of one with the
FragmentExtractorGenerator that will make recursive
sitemap calls for you.

AW: [C2]: What happened to Roles.COCOON?

[Carsten Ziegeler <cz...@sundn.de>]

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

Carsten 

Re: [C2]: What happened to Roles.COCOON?

[Giacomo Pati <gi...@apache.org>]

Carsten Ziegeler wrote:
> Hi,
>
> after updating to the latest CVS the Roles.COCOON has disappeared!

Yes, read the mail from berin from last night .

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

Giacomo

Re: AW: [C2]: What happened to Roles.COCOON?

[Berin Loritsch <bl...@apache.org>]

Carsten Ziegeler wrote:
> 
> > Berin Loritsch wrote:
> > Yes it is intentional.  Any information that you would have gotten
> > from the Cocoon object can be gotten from the App Context object.
> > Make your class Contextualizable, and get your info from the
> > Context that was passed to you.
> Yes, I understand now. But I can't get a Cocoon instance or a Processor
> from the Context, right?
> I need an (initialized) object which can process an environment for my purpose.
> 
> Can any component (generator, transformer, even a the parser) implement the
> Contextualizable interface to get the Context?

If not, then soon.  The sitemap ComponentManagement system is one of
the tasks on my todo list.

Re: AW: [C2]: What happened to Roles.COCOON?

[Giacomo Pati <gi...@apache.org>]

Berin Loritsch wrote:
> Carsten Ziegeler wrote:
> > > Berin Loritsch wrote:
> > > Yes it is intentional.  Any information that you would have gotten
> > > from the Cocoon object can be gotten from the App Context object.
> > > Make your class Contextualizable, and get your info from the
> > > Context that was passed to you.
> >
> > Yes, I understand now. But I can't get a Cocoon instance or a Processor
> > from the Context, right?
> > I need an (initialized) object which can process an environment for my
> > purpose.
> >
> > Can any component (generator, transformer, even a the parser) implement
> > the Contextualizable interface to get the Context?
>
> Ok, we might need to make the Sitemap a Component that can be retrieved.
> I will look into this.  It will help with Content Aggregation and such.

Well, see my last mail ho this can be achieved. And yes, the Sitemap engine 
could be made a Component for that.

Giacomo

AW: [C2]: What happened to Roles.COCOON?

[Carsten Ziegeler <cz...@sundn.de>]

> Berin Loritsch wrote:
> Ok, we might need to make the Sitemap a Component that can be retrieved.
> I will look into this.  It will help with Content Aggregation and such.
> 
Yes, that sounds great, I am +2 on this.

Carsten

Re: AW: [C2]: What happened to Roles.COCOON?

[Berin Loritsch <bl...@apache.org>]

Carsten Ziegeler wrote:
> 
> > Berin Loritsch wrote:
> > Yes it is intentional.  Any information that you would have gotten
> > from the Cocoon object can be gotten from the App Context object.
> > Make your class Contextualizable, and get your info from the
> > Context that was passed to you.
> Yes, I understand now. But I can't get a Cocoon instance or a Processor
> from the Context, right?
> I need an (initialized) object which can process an environment for my purpose.
> 
> Can any component (generator, transformer, even a the parser) implement the
> Contextualizable interface to get the Context?

Ok, we might need to make the Sitemap a Component that can be retrieved.
I will look into this.  It will help with Content Aggregation and such.

AW: [C2]: What happened to Roles.COCOON?

[Carsten Ziegeler <cz...@sundn.de>]

> Berin Loritsch wrote:
> Yes it is intentional.  Any information that you would have gotten
> from the Cocoon object can be gotten from the App Context object.
> Make your class Contextualizable, and get your info from the
> Context that was passed to you.
Yes, I understand now. But I can't get a Cocoon instance or a Processor
from the Context, right?
I need an (initialized) object which can process an environment for my purpose.

Can any component (generator, transformer, even a the parser) implement the
Contextualizable interface to get the Context?

Carsten

Re: [C2]: What happened to Roles.COCOON?

[Berin Loritsch <bl...@apache.org>]

Carsten Ziegeler wrote:
> 
> Hi,
> 
> after updating to the latest CVS the Roles.COCOON has disappeared!
> 
> Was this removing intentionally? And why?
> 
> How can I get the Cocoon instance now? A simple ComponentManger.lookup(Roles.COCOON) does of course not work anymore.

Yes it is intentional.  Any information that you would have gotten
from the Cocoon object can be gotten from the App Context object.
Make your class Contextualizable, and get your info from the
Context that was passed to you.