cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Fri, 29 Aug 2003 12:19:21 GMT

Stefano Mazzocchi wrote, On 28/08/2003 17.27:

> On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote:
>> >Calling a resource, inserting a virtual pipeline and using the 
>> cocoon: protocol are for most uses equivalent.<
> I agree when you say that since the introduction of the cocoon: 
> protocol, map:resource is now redundant (and less appealing, as well). 
> In fact, we could go as far as saying that <map:resource> is no longer 
> needed and could be deprecated.
> This would leave us only with pipelines, components and virtual 
> components (which are, in fact, typed pipeline fragments), and the 
> cocoon: protocol to mix them, if needed.

+1 from me for this

>> (I won't use AOP terminology that I personally don't yet like)
>> >See, I don't like it too! ;-)<
> well, when you propose something like <map:aspects> it seems AOP-ish 
> enough for me ;-) that's not coherent with the above.

Only the name "aspect". I refrained talking about pointcuts, advises, 
etc... (ugh, I do hate those...)

>> So we can generalize it, and add configurability to the view mechanism
>> to specify other conditions.
>> >Thus views effectively insert pipeline fragments at a certain 
>> condition. In fact they insert their contents after a label.
>> So the label is the condition.
> I know it's a matter of terminology pickyness, but I disagree. The 
> condition that triggers the view is the view request. The result of this 
> condition is the execution of the pipeline that is 'instrumented' to 
> route its output somewhere else (to the view, which can now be seen as a 
> virtual serializer)

Correct. You know how messy I am in describing things. Put the right 
terminology instead of condition.

> you are using AOP the micro-granular way. This is: remove crosscutting 
> by making all overlapping aspect objects and compose them together.
> I tend to dislike this practice since it leads, IMHO, to poor 
> readability (users don't have the vision of crosscutting concerns that 
> we developers do, and they perceive it as unnecessary overcomponentization)
> a critic to the above is: why would you want to gather-links if you are 
> not going to serialize them?

Yes, I've come to the same conclusion yesterday too.

> You are suggesting that a more general aspect-oriented approach to 
> pipeline composability might be general enough to allow views to be 
> replaced by such a more powerful approach.
> I agree.


> What I don't understand is why we should give away a perfectly fine 
> system for a new flexibility we don't need. [note how I avoided to named 
> this FS even if I was very tempted to do so ;-)]


Yes, I see this too now.

The RT started out of a link-gathering evolution, and for that only it 
may be too much...

>> This would make it very easy to add security-based checks, logging, or
>> any other stuff.
>> <map:aspects>
>>   <map:aspect type="pipeline" test="start">
>>     <map:action type="check-security"/>
>>   </map:aspect>
>>   <map:aspect type="pipeline" test="all">
>>     <map:transformer type="logger"/>
>>   </map:aspect>
>>   <map:aspect type="error" test="all">
>>     <map:action type="notify-admin"/>
>>   </map:aspect>
>> </map:aspects>
> I don't like this and I don't see any reasonable use of the above system 
> besides views. [c'mon, a logging aspect is much easier implemented by a 
> different pipeline implementation, an admin-notifier is much better 
> placed in a error-handler, where it belongs, and for flow-related 
> actions, well, you know my opinion on those]
> What am I missing?

Simple: AOP does not make you do more things, it factorizes common 
behaviours in a single place. If the places where these things must be 
placed are a lot, then it makes sense, else it doesn't.

You have much more experience in seeing working systems, so you can 
judge better than me on this.

>> *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.
> This is probably the point I'm missing.
> Instead of discussion the solution, can't we start over again from the 
> problem? maybe there are easier solutions that you didn't think about.

This is the last iteration of a looong discussion ;-)

  - CLI crawling link-views is slow
  - it's slow because it's multipass
  - make it monopass by instrumenting the pipeline with a gatherer
    - this brings >50% speed increase
  - but the instrumentation is not configurable:
    - no place where to tell where ti gather
    - no link filtering
  - add a filter to the links (done in CVS)

  - Vadim has the idea of using a tee instead

So let's leave this where it is now till some real need comes up, and 
let's continue the thread from the last mail of Upayavira on this.
Below the last comments.

>> What do others think?
>> Is it already possible to do this today with other components and
>> skillful pipeline writing?
> what do you mean with "this"?

All the above stuff.

>> For doing it at the beginning or at the end
>> of a request it's possible to have an entry-point pieline that has pre
>> and post processing, but to add stuff *inside* other pipelines? I think
>> it cannot be done today.
> Sorry, but I'm lost.

I mean, if I want to add something before all processing and after all 
processing, I can simply make a match for **, that has something at the 
beginning and something at the end, and inject the content in the middle.

To insert an action before and skinning after this:

  match: **
   generator: {1}
   serializer: xml

I can do:

  match: **
   action: pre
   generator: cocoon://internal/{1}
   transformer: skin
   serializer: html

  match: internal/**
   generator: {1}
   serializer: xml

But I cannot insert anything inside  ..(*)..
With aspects I can... conceded there is a need for it, of course.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message