cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Thu, 28 Aug 2003 14:23:33 GMT
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



Mime
View raw message