Stefano Mazzocchi wrote, On 26/08/2003 18.43: ...
I would like Nicola to update its RT on aspectizing the sitemap after the introduction of virtual components (which, IMO, solve most of the issues he outlined).
Actually I already reference the concept:
"Hmmm, it also has to do with the "named pipelines" thread, or the pipeline==reusable_component one that Stefano had started."
But I don't see a real direct benefit of virtual components in this RT yet as it's not the main point it seems to me.
What is not covered, IMO, can be implemented by extending the view concept.
Which is basically what the while RT is about IMHO. I see how things work now, how the view concept can be extended, and then how "aspectized" pipelines can be a bigger generalization of views.
Below is the salient part of the RT with additions and comments in >brackets<
>Now I describe the current situation<
- <pipelines> are called per request one after the other till the sitemap exits - <resources> are sitemap snippets called by the pipelines - <views> are exit points that get called at a particular label (effectively a hard-wired AOP feature) by the sitemap
Pipelines and resources are effectively the same thing not that there is the cocoon protocol.
>Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent.<
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.
<
(I won't use AOP terminology that I personally don't yet like)
>See, I don't like it too! ;-)<
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.
*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.<
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".
*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>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>> 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.
<
What do others think?
Is it already possible to do this today with other components and skillful pipeline writing? 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.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------