Michael Melhem wrote:
Hi, Ok, here is a little "rant" on flow/sitemap intergration :)
First, let me tell you that I link your ranting style a lot :)
And this might be a first strong hypthesis in your reasoning that must be taken into consideration.1. What Is A Cocoon Pipeline? There are at least two concepts of pipeline in cocoon. 1.1 The Sitemap Pipeline. A sitemap-pipeline basically acts as a "recipe" on how to build a processing-pipeline. Sitemap-pipelines contain information on the type of processing-pipeline to use, and the set of processing components to be attached to them. Typically, the purpose of each "sitemap-pipeline uri" is to build a specific processing-pipeline. (Of course entry points into pipelines/flows need not be URI's, one can match on "whatever", but for purposes of this mail, I will stick to URIs)
The above is slightly incorrect, I would say:1.2 The Processing Pipeline There are several different types of Processing Pipelines, noncaching, caching, caching-point, profiling, hintable etc.. The processing pipeline is in effect the SAX-conducting "glue" or "pipe" which holds the pipeline components together. Usually an XML stream flows down this pipe and gets transformed by each of the pipeline components until it gets serialized by the last pipeline component - the serializer (no surprise here). 2. What is A Flow? A flow is controlled navigation through a set of processing-pipelines.
- a pipeline is the way cocoon uses to produces resources (readers can be seen as 'condensed pipelines' for non-XML resources)
- a flow is controlled navigation thru a set of resources
the difference is the level of indirection provided by the URI space that provides the contract between the two. This is important to be able to separate the flow from actual pipeline descriptions and keep concerns separate.
Again, the flow controls navigation between a logical set of 'resources', not pipelines. The fact that those resources are associated to pipelines is merely an implementation detail in this context.That is, the purpose of "flow uri" is _not_ to build a processing-pipeline, but rather, to define a application specific flow through a logical set of them.
I do see your point but still your terminology might be misleading... more comments below.This means a "flow-uri" is not same as a "sitemap-pipeline uri". Conceptually flow URIs are not part of pipelines at all, they are extra-pipeline. They act on pipelines.
Oh boy, it's already hard enough to indicate what is a good URI, if we start discussing what is a 'flow uri' compared to a 'resource uri' we get in trouble.--- So I find the notion of "flow uri's" living side by side with "sitemap-pipline uri's" inside pipeline sections a little awkward. There seems to be some muddling of concerns here.
Infact, although flow function are defined within
"pipeline sections", they ignore them.
<map:pipeline type="has_no_ effect_on_flow_uri">
<map:match pattern="loginFlowUri/">
<map:call flow="login"/>
</map:match>
</map:pipeline>
I totally agree with you.
Heck, my original intention was to separate the sitemap into sitemap (for resource) and flowmap (for flow)... but we didn't have an implementation back then, it was everything up in the air.... now we do have something that works, maybe we should start discussing this again.Implementation details aside, IMO, it would much cleaner if we could define a flow-uri mapping (a flowmap) and keep it together with the flow defintion itself.
For example, one can define a flow for a sitemap like this:
<map:flow language="JavaScript">
<map:script src="prefs.js"/>
<map:flowmap>
<map:match pattern="kont/*">
<map:call continuation="{1}"/>
</map:match>
<map:match pattern="login/">
<map:call function="login"/>
</map:match>
<map:match pattern="register/">
<map:call function="registerUser"/>
</map:match>
<map:match pattern="logout/">
<map:call function="logout"/>
</map:match>
</map:flowmap>
</map:flow>
This way we actually define the "uber-contoller" for the sitemap
in one place leaving the pipeline section as follows:
<map:pipelines>
<map:pipeline>
...
<map:match pattern="body-examples/*/**.xml">
<map:generate src="examples/{1}/pages/{2}.xsp" type="sp"/>
<map:transform src="stylesheets/document2html.xsl"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="body-**.xml">
<map:generate src="docs/{1}.xml"/>
<map:transform src="context://.../document2html.xsl"/>
<map:serialize/>
</map:match>
</map:pipeline>
...
</map:pipelines>
This way (with most actions and flow logic moved into the flow),
sitemap-pipelines become just that, pipelines!
Conceptually a client can either invoke pipelines via flow (indirectly),
or invoke a pipeline directly.
---
If it is decided that best practice is to disallow actions
and routing components around flow calls:-
<map:match pattern="login/">
<!-- no sitemap routing/Acting components allowed -->
<map:call function="login"/>
<!-- no sitemap routing/Acting components allowed -->
</map:match>
Then perhaps the flowmap can be further simplified by introducing
a new sitemap element "map:map". This means we can rewrite the
flowmap section as follows:
<map:flowmap>
<map:map uri="login/" flow="login">
<map:map uri="register/" flow="registerUser">
<map:map uri="logout/" flow="logout">
</map:flowmap>
This way we enforce best practice and keep routing control
in the flow and out of the sitemap.
I wonder, is this the case? by getting rid of matchers, we are also getting rid of the ability to keep them pluggable... and first objection would be 'how do I match flow URI with regexp?'
I like your concepts, anyway, let's see what others have to say about this.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
