cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Extending the Bean (non-HTML)
Date Mon, 18 Aug 2003 16:04:37 GMT
Upayavira wrote:

>>> But we did document that the API of the bean was unstable. Doesn't 
>>> that mean we can change the API where necessary?
>> Ah, in this case we can. Unfortunately, class's Javadoc does not has 
>> this indication. 
> How do you use Javadoc to indicate unstable?

<p><b>WARNING:</b> This interface is not stable and could be changed in

backward incompatible way without prior notice.</p>


> I've got it working now, but I've lost linkGatherer functionality and 
> it seems slower.

Add some heavy XSLT transformations. Say, calculation of number pi :)

> I've started looking into reimplementing linkGatherer, by, every time 
> I see saying something like (using pseudo-code):
> if (objectModel.contains(LINK_GATHERER_LIST) {
> + "/gathered-links", 
> objectModel.get(LINK_GATHERER_LIST);
> }
> Does that seem reasonable?

I don't know what this code is for. I guess for caching of the collected 
links... Are they used later on anywhere?

> Is it easy to build up the 'key + "/gathered-links" '  composite cache 
> key? 

It should not be too hard. You can benchmark this using some simple 
stand alone program.

>>>>> * 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.
>> Ah, I see. But there, you will have to go over the wire, as Crawler 
>> does. Right? 
> Reading Unico's recent email, it makes sense to use FOM_Cocoon if the 
> bean is to be used in a servlet environment. Then the bean becomes 
> something quite simple. Would you agree?

Using flowscript's FOM_Cocoon to process requests? Yes, sounds right.

>>>>> * work out how to implement Vadim's idea for a single pipeline with
>>>>> an  XMLTeePipe to generate both a link view and page view in one hit
>>>> Yep. Should increase performance and conformance!
>>> I've spent some time trying to work out how to do this. It seems 
>>> quite complicated. As each pipeline, when built, is made up of 
>>> generator, set of translators and serializer, to build a pipeline 
>>> which splits into two, one half completing normally and the other 
>>> going off into a separate 'link-view' pipeline, would require a 
>>> specifically built Pipeline class, and would require changes to the 
>>> treeprocessor to be able to build it. Am I right, or do you know of 
>>> a simpler way?
>> You are right. As currently sitemap implementation adds link gatherer 
>> automagically, in the same way links view should be automagically 
>> assembled and attached at the branch point. 
> But to do it automagically would require significant changes to, 
> probably, AbstractProcessingPipeline, as for automagicallity, you 
> couldn't add a special 'BranchingCachingProcessingPipeline'. Is that 
> what you would propose?

Probably, yes, AbstractProcessingPipeline will require support for 
ViewTee... I'd not create special BranchingCachingProcessingPipeline if 
modifying of existing classes is easy enough.


View raw message