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.
Ok.
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 ;-)
Summary: - 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: xmlI can do:
match: **
action: pre
generator: cocoon://internal/{1}
transformer: skin
serializer: html match: internal/**
generator: {1}
..(*)..
serializer: xmlBut I cannot insert anything inside ..(*).. With aspects I can... conceded there is a need for it, of course.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------