The link stuff is a cross-cutting concern. This thread has IMHO shown how aspects can be easily added to the sitemap, and effectively used.
Let's see...
Jeff Turner wrote, On 29/06/2003 14.48:
On Sun, Jun 29, 2003 at 11:34:01AM +0200, Nicola Ken Barozzi wrote:
Jeff Turner wrote, On 29/06/2003 8.03:
....- We're abusing the name 'transformer', since nothing is transformed. If we're really going to go this way, let's define a new sitemap element, <map:link-gatherer/>.
There are transformers that do not transform, it's not unusual,
I can't think of any others?
some OTOMH, maybe not 100% correct:
LogTransformer XMLFormTransformer WriteDOMSessionTransformer SourceWritingTransformer
<snip links to stuff I mostly missed - thanks>
" So basically we are adding a contract to the sitemap, by saying that each sitemap implementation has to provide a list of links if requested to (as seen above). "
As you state, a Transformer does not feel right. In fact, a sitemap has now a new contract that it has to give links. The question is: how can it be made more versatile? Who can we tell the pipeline where we want the link gathering to occur?
What about a named pipeline that is inserted by the link gatherer where it gets the links? What about using a spacial label to indicate where to gather links?
Hmm.. interesting. Perhaps we just need to augment Resources a bit:
<map:resource name="gather-links" from-position="content"> <!-- Any required link munging --> <map:transformer type="gather-links"/> </map:resource>
Cool, you have put my words in code, adding that last bit that makes them worthwile :-)
This really looks like some sort of final solution, intriguing.
Hmmm, it also has to do with the "named pipelines" thread, or the pipeline==reusable_component one that Stefano had started.
Seems like simply adding this capability to resources is nice. We could similarly make a link-view that uses the same transformer and a serializer. In this way it could also be compatible with the 3pass method. Hmmm...
Ie, a Resource inserted in each pipeline after the 'content' label. Rather AOP'ish.
Yup. As link gathering is a cross-cutting concern, it also makes sense conceptually.
The thing here is how it's called by the sitemap engine. There is no explicit call in the pipelines, but instead a "from-position" attribute. It could easily have also a serializer, and in this way it would terminate all pipelines... but it's like a view in this case...
But a view then would become an AOPish resource with a serializer called only on certain conditions. Let's call them aspects instead of resources.
So:
- <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.
What remains is the <views> part, that has introduce pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met (I won't use AOP terminology that I personally don't yet like)
So we can generalize it, and add configurability to the view mechanism to specify 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.
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.
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>
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.
Just food for thought.
Tasty..
I really appreciate it, and how you manage to work with me even when I'm a bit touchy. Thanks :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------