cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Thu, 28 Aug 2003 13:06:45 GMT
Vadim Gritsenko wrote:

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

You are right - Nicola Ken is here mixing up Link View and Link 
Gathering - two different approaches. What he says though is relevant to 
the link gathering approach, i.e. that it could be implemented with an 
'aspect' allowing the user to insert the gathering stage at any point in 
their pipeline, by attaching a gathering transformer to a label 
(defaulting to the last stage, just before the serializer).

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

Interesting point. That would also apply to the link translator, which, 
if confirm-extensions is used (which it is by default), is inserted 
before the serializer. So, to be able to pre-populate a persistent 
cache, you've got to (a) use link view (b) make sure you don't confirm 
extensions.

> 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) 
> and Upayavira is looking into ways of implementing it. I would help 
> him out but right now I can't.

Having reread Nicola Ken's post, I think I understood it this time 
(rather than being confused by all the references to aspects as I was 
last time).

He does propose an interesting and more generic way to achieve what 
Vadim has already suggested - using an XML Tee component to feed SAX 
events into two pipeline segments simultaneously. To do that hard coded 
would be hard, and require quite a bit of work within 
AbstractProcessingPipeline. Doing it in Nicola Ken's way strikes me as 
cleaner and more generic. So you'd be able to add 'aspects' that use 
generators/transformers/serializers in the following combinations:

1) G-T-S (pretty useless as it doesn't really interact with the pipeline 
as it is)
2) T-S (takes the current SAX events, using a Tee, and feeds them to a 
section of pipeline that serializes somewhere else - e.g. link view)
3) G-T (replaces or augments SAX events with an additional source)
4) T (transforms existing SAX events, e.g. link gatherer)

So we get a generic way of implementing our two gathering methods, and 
probably some additional methods we hadn't thought of.

In case 2), we'd probably want to have another component after the 
serializer which defines what to do with the content, e.g. an 
ObjectModelWriter that writes it to the ObjectModel, a FileWriter that 
writes it to a file (or more likely a SourceWriter).

Does this make sense? Or is it barking? (barking is shorthand for 
'barking mad', like wild dogs can be sometimes).

Regards, Upayavira



Mime
View raw message