Re: Extending the Bean (non-HTML)

[Upayavira]

Unico Hommes wrote:

* Make Cocoon work with an external Cocoon object, again for the  
sake of a PublishingService
       

I don't get this. What Cocoon with which external Cocoon?
     

This is something that Unico talked about in relation to a 
publishing service running within a Cocoon servlet. Again, 
I'll wait until we've got an actual plan for such a service.


I did talk about this. I thought that we might be able to use CocoonBean
for such a service if only we could make it less monolithic and factor
out cocoon creation. However I've since found some other very good
alternatives that I think have definate advantages over CocoonBean. For
instance in FOM there exists the
cocoon.processPipelineTo(uri,biz,stream) that lets you process the
pipeline identified by the uri argument to the stream argument.
That's fine if you just want a single page. But what if you want to 
crawl? Or do you use your own crawler to invoke cocoon.processPipelineTo()?

Another possibility is the SitemapSource that was recently patched to
understand cocoon-view semantics (cocoon:/path?cocoon-view=links). This
allows for a CocoonCrawler implementation that crawls internally instead
of over the network like the current one (except that it takes URL
objects (to wich custom schemas are malformed)).
Anyway, this to say that a publisher service instead of running on top
of cocoon should probably use those mechanisms. 

Interesting. I'm refactoring the bean at the moment, and my next 
refactor is to extract out the crawling code into a separate class. Once 
that's done, it would be possible to make the bean optionally use the 
FOM_Cocoon object along with the processPipelineTo() method. In that 
situation, the bean would be a much more lightweight component. That's 
now on my todo list, as it gives the bean a cool way to run within a 
servlet environment, but without all of the weight of a second instance 
of Cocoon.

If CocoonBean has the
code for bootstrapping the Cocoon system then possibly in the future
CocoonServlet could delegate some of those responsibilities to it. 

In theory, yes. But the servlet is a kind'a special case.

I
don't think CocoonServlet will need the Target abstraction and it will
run Environments directly on Cocoon and so I think it's a good idea to
split up CocoonBean this way.
Sorry, I don't understand? CocoonServlet doesn't need the Target 
abstraction, but a CocoonBean using FOM_Cocoon will need something like 
that, won't it?

Regards, Upayavira