Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E06C747.9020407@apache.org>
Date: Mon, 23 Dec 2002 00:20:23 -0800
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Flow/Sitemap Integration
References: 
 <Pine.LNX.4.44.0212191745190.10599-100000@fztig938.bank.dresdner.net>
In-Reply-To: 
 <Pine.LNX.4.44.0212191745190.10599-100000@fztig938.bank.dresdner.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I know almost everybody is idle for the holydays, but I want to reply to 
this before I forgot :)

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 :)

> 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)

And this might be a first strong hypthesis in your reasoning that must 
be taken into consideration.

> 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.

The above is slightly incorrect, I would say:

  - 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.

> 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.

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.

> 
> 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.

I do see your point but still your terminology might be misleading... 
more comments below.

> ---
> 
> 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.

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.

> 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>

Now, discussions aside, *this* is a valid point and shows some 
'hackiness' in the current semantics.

I totally agree with you.

> 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.

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.

> 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.

Assuming you want to keep that semantics all in the sitemap (you don't 
specify so, but I would tend to see that)... we must define the order of 
matching preference between <flow> and <pipelines>

> ---
> 
> 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.

Hmmm, this is an interesting concept but this doesn't only prevent the 
use actions before calls (something which I'd deeply love to see 
enforced, but that's my personal view, of course, and you all know my 
stand against actions) it also *forces* the flow calls to be tied to URI 
matching.

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                               <stefano@apache.org>
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org