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.
What remains is the <views> part, that has introduced pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met
>IOW, I'm rephrasing, using different terminology, that a view is an orthogonal mechanism, that interacts with the normal sitemap using some metadata and an exit pipeline.
The labels are effectively metadata, as they describe the pipeline.
The exit pipelines, ie the views themselves, are what has to be done.
<
Yes, views are orthogonal pipelines.
(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.
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)
*first proposal* I propose that we define other conditions.<
<map:view name="content" from-label="content"> <map:serialize type="xml"/> </map:view>
becomes:
<map:view name="content" type="from-label" test="content"> <map:serialize type="xml"/> </map:view>
This makes it possible to make a different position where to start from...
What can also be made configurable is *when*, in which condition, it's triggered, but the logic has to be inverted.
>What I mean here is that views are triggered only by the user. Normal results are done *without* calling views. So if I want to say: insert a logger after each generator, I cannot do it easily, as I would have to call a "logger-view" for it to be called. And I would have only one possible insertion per pipeline, as only one view is called at a > time.<
ok, now I get it
Now we say: "when the view is triggered, start at a label" After it could be: "when the view is triggered, start at position" Instead we need: "when the position is met, check if it has to be triggered".
Here is an example that uses this "inverted" AOPish system for views.
>Let me rephrase this: the following is a way of defining views in a more generic way. Here I don't say anymore: "when the user asks for a view trigger the label (or more generic as in the first proposal) condition", but "at every stage check if a condition is met, and if so execute the "generalized view".
hmmmmm
*second proposal*
Make it possible to tell Cocoon to add pipeline snippets (ie virtual pipelines) given certain rules. This makes it possible to have views be made with this more generic mechanism.
<
The following adds two aspects:
- an aspect gets called from every content position and gathers links.
- the other one gets called from every content position. If the
request has a cocoon-view=links, then the links are serialized.
<map:aspects>
<map:aspect type="from-label" test="content">
<!-- Any required link munging -->
<map:transformer type="gather-links"/>
</map:aspect>
<map:aspect type="from-label" test="content">
<map:action type="request-param">
<map:param name="cocoon-view" value="link">
<map:serializer type="links"/>
</map:action>
</map:aspect>
</map:aspects>
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?
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 ;-)]
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?
> With virtual pipelines (vp) we could as well do:
<map:aspects> <!-- if the "from-label" condition of the current pipeline component matches "content", then insert right after it the virtual pipeline called gather-links and content-view. IOW add a link gatherer and a link view after each content labeled component.--> <map:aspect type="from-label" test="content" vp="gather-links"/> <map:aspect type="from-label" test="content" vp="content-view"/>
<!-- if the "pipeline" condition of the current pipeline component matches "start", then insert right after it the virtual pipeline called check-security. IOW add a security check at each pipeline start.--> <map:aspect type="pipeline" test="start" vp="check-security"/>
<!-- if the "pipeline" condition of the current pipeline component matches "all", then insert right after it the virtual pipeline called logger. IOW add a logger after each component.--> <map:aspect type="pipeline" test="all" vp="logger"/>
<!-- if the "error" condition of the current pipeline component matches "all", then insert right after it the virtual pipeline called check-security. IOW notify the admin when the error pipeline gets called.--> <map:aspect type="error" test="all" vp="notify-admin"/>
</map:aspects>
Note that the virtual pipeline can also contain the call to the flowscript, so I can effectively ask Cocoon to pass any condition to the flow, and use it for more effective management.
*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.
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"?
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.
-- Stefano.
