Hi,
Ok, here is a little "rant" on flow/sitemap intergration :)
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)
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.
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.
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.
---
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>
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. Much like defining a class interface.
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.
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
