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 cache.store() saying something like (using pseudo-code):
if (objectModel.contains(LINK_GATHERER_LIST) {
cache.store(key + "/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 time.
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 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.
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
