Nicola Ken Barozzi wrote:
>
> 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
|