cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Extending the Bean (non-HTML)
Date Sun, 17 Aug 2003 15:54:51 GMT
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.

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

View raw message