Vadim Gritsenko wrote, On 28/08/2003 14.00:
Nicola Ken Barozzi wrote: <snip/>
*IMPORTANT* (and the reason why I started the RT):
So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would.
This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer.
Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view.
When I say Transformer here I mean Virtual Transformer, that can be all you say above, as I suggest in the RT. This also means that this virtual Transformer can also do the link exclusion and other things that are needed and that a simple transformer cannot do.
In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache.
I do not see the case in which this happens. Could you explain more please?
Somebody had an idea of running CLI to pre-populate Cocoon cache so when servlet is running all the pages are already cached. But there is a problem preventing doing so, currently observed with CLI working with LinkGatherer (later: LG). When running from the CLI, pipeline assembled, and key generated, is G-T-...-LG-S, and resulting page is stored in the cache. When running as a servlet, key is G-T-...-S (no GT anymore), and cache lookup returns null.
Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see "Link View Goodness" on approx 2003/07/01)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105708533500966&w=2
and Upayavira is looking into ways of implementing it. I would help him out but right now I can't.
I know, but doing it as I say is conceptually equivalent to attaching links tee to main pipeline, so it's an alternative way, but that has extra features.
Conceptually
generator >inserted gatherer vt< --- (links hashmap) serializer
What propose
generator >inserted tee -> view -> parser< --- (links hashmap) serializer
Which is basically the same, only that I use a virtual transformer and you use a view. Make the view call the same virtual transformer, and the results are the same only that my proposal is more generic.
Oh well, whatever, as long as it works...
May be I'm missing something. How the following setup will work with your proposal:
<map:view name="links" from-label="content"> <map:transform src="links.xsl"/> <map:serialize type="links"/> </map:view>
<map:pipeline> <map:generate src="data.xml"/> <map:transform src="content.xsl" label="content"/> <map:transform src="page.xsl"/> <map:transform src="html.xsl"/> <map:serialize type="html"/> </map:pipeline>
With a "tee-view", pipeline would be: G[data] -> T[content] -> Tee -> T[page] -> T[html] -> S -> Browser \ -> T[links] -> Hashmap
With a "virtual transformer" as far as I understand resulting pipeline will be:
G[data] -> T[content] -> T[links] -> LinkGatherer -> T[page] -> T[html] -> S -> Browser
And the output sent to the browser will be garbage, right? Or, you are also proposing to use a tee (I haven't seen it in your proposal)?
Vadim
