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 Mon, 18 Aug 2003 19:27:28 GMT
Vadim Gritsenko wrote:

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

Ah. That's easy!

>> 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'll give that a go.

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

Basically, if the page comes from the cache, you still need to get the 
links, but can't get them from the LinkGatherer, as it's not called. So, 
when LinkGatherer is called, it needs to cache its links ready for next 

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

What I mean here is that I need to build some kind of composite key if 
I'm going to store the links in the cache. I was suggesting basing the 
key on the page's key, with some kind of alteration.

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

It's now on my list.

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

I'll look into it. How could I present any changes? I can't really 
commit changes that'll might break other things. Post a patch?

Regards, Upayavira

View raw message