cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Flowmaps
Date Sun, 16 Jun 2002 20:10:07 GMT
Stefano Mazzocchi wrote:

> The problems with this approach
> -------------------------------
> First of all, let me say that I consider the above concept the biggest
> advancement in server-side web technology since servlets.

I would say since web servers.

Some weeks ago I showed it to a friend of mine that I have been helping 
out on C2 for his-our value-chain management system, and he almost fainted!

Ten minutes after I showed it to him, that is, since it takes some time 
for the concept to get to the correct neurons ;-)

I've snipped the analysis, which I find correct and clean, as always :-)

> More explicit sitemap markup
> ----------------------------
> Here is what I think would be a much better approach to connect a
> sitemap and a flowmap:
> <map:sitemap xmlns:map="">
>   <map:flowmaps default="calculator">
>    <map:flowmap name="calculator" src="calc.js" language="javascript"/>
>   </map:flowmaps>
>   <map:pipelines>
>    <map:pipeline>
>     <map:match pattern="">
>      <map:call function="calculator('prefix','/kont')"/>
>     </map:match>
>     <map:match pattern="kont/*">
>      <map:call with-continuation="{1}"/>
>     </map:match>
>     <map:match pattern="*.html">
>      <map:generate src="{1}.xsp" type="serverpages"/>
>      <map:serialize/>
>     </map:match>
>    </map:pipeline>
>   </map:pipelines>
> </map:sitemap>

I think that
      <map:match pattern="kont/*">
       <map:call with-continuation="{1}"/>

Is unnecessary and *will* create confusion, since there is no way to 
enforce it while using a flowmap.
Users will forget to write it and flood us with mails of "why doesn't it 

How about:
      <map:match pattern="">
       <map:call function="calculator('prefix','/kont')


> There are a couple of major differences:
>  1) a flowmap isn't a sitemap resource, but it's something else. The
> above semantics reflect this.

+1  The sitemap should reflect real semantics, ie flowmap!=resource

>  2) you can have more than one flowmap in a sitemap (then you can define
> a default one or use a 'flowmap' attribute in "map:call" to identify
> which flowmap you are calling)
> [of course, in order to accomplish this, the implementation must
> completely isolate the different flowmaps and its global variables]

+1  This is almost obvious, but very important to state.

>  3) the "map:call" element is used to call sitemap resources (pipelines)
> and flowmap resources (functions), an attribute is used to indicate the
> behavior that should be used and it's consistent with the rest of the
> sitemap.


Is a flowmap a resource or not?

>  4) the "map:call" element can use both nested map:parameters or
> directly using the 'function(param, param)' syntax inside the attribute.
> This makes it more readable in some cases.


The more xml we use in the sitemap, the more validations-enforcements we 
can have.

> Making continuations transparent
> --------------------------------
> I personally don't have a clear view of the usability of this concept
> myself: I like it very much, it's clear and consistent and it's similar
> to the session concept.
> The only thing is that we might provide a
> "ContinuationURLEncodingTransformer" of some sort to separate the
> concern of those who write the forms and those who write the sitemap,
> even if, passing the 'kont/' prefix as I showed above allows to keep the
> URI space totally self-contained in the sitemap.

Yes, I understood that we should have the sitemap define the uri needed 
to "store" continuations, see above for a possible solution.

> I'd be happy to hear more comments in this area (Daniel?)
> More ways to get flowmap data
> -----------------------------
> Currently, in order to have access to flowmap data (parameters or
> continuations), you need to use the XSP or write java code yourself (I'm
> not even sure the latest is possible, Ovidiu?)
> I'd like to have at least a few others:
>  1) XSTL
>  2) Velocity
>  3) JSP?
> I don't know how hard it is to implement them and I'd like to have
> suggestions on how to implement at least the first one (the problem with
> velocity is that its output must be parsed, unlike XSP, so Velocity
> templates are inherently slower than a compiled XSP, but at least they
> are easier to understand and to use for many, expecially HTML
> designers).
> Using JSP as an MVC view makes sense in those cases where a tool is
> required for HTML designers to connect to the parameters passed to the
> JSP. I personally don't care but others might.

Why would you need access to continuations?
I think they should remain transparent.

As for parameters, can't we make them available in the Sitemap Context, 
so that no new stuff is necessary?

> There is only one big thing missing: when I thought originally at the
> flowmap concept, I wanted it to be interchangeable with the sitemap, now
> I've changed my mind and I think it makes sense to have a sitemap always
> up front, no matter how 'procedural' your web application is (might even
> have a single URI for the whole thing and handle everything inside the
> flowmap)

Since we need a sitemap to manage the URI space, it makes sense.

> At the same time, when I was explaining the flowmap concept to the guys
> at SwissRisk, we came up with an idea [gosh, forgot the name of the guy
> who suggested me to think in that direction, hope he is subscribed and
> makes himself known!].
> Consider this flowmap call
>    sendPage("hello.html");
> this means:
>   1) ask the sitemap to redirect to "hello.html"
>   2) send the output to the client
>   3) wait for a request to make me continue
> Now, suppose we do this
>    callPipeline("hello.html", input, output);
> where we mean:
>  1) call the internal "hello.html" URI connecting the input and output
> that I give you.
>  2) come back here without sending anything to the client
> <drum-roll/>
> VOILA'! We have the ability to use serializers to write on disk, without
> even touching the sitemap!
> So, consider this sitemap:
> <map:sitemap xmlns:map="">
>   <map:flowmaps default="editor">
>    <map:flowmap name="editor" src="editor.js" language="javascript"/>
>   </map:flowmaps>
>   <map:pipelines>
>     <map:pipeline internal="true">
>       <map:match pattern="save2disk">
>         <map:generate type="stream">
>           <map:parameter name="content" value="content"/>
>         </map:generate>
>         <map:serialize type="xml"/>
>       </map:match>
>     </map:pipeline>
>     <map:pipeline>
>       <map:match pattern="save">
>        <map:call function="save2disk()"/>
>       </map:match>
>     </map:pipeline>
>   </map:pipelines>
> </map:sitemap>
> and your flowmap is something like
> function save2disk() {
> 	OutputStream output = new FileOutputStream("/usr/local/docs");
> 	callPipeline("save",cocoon.request, output);
> }
> it would be *THAT* easy!
> [NOTE: the 'input' and 'output' parameters of the callPipeline() method
> will have to be carefully choosen, here I'm just making this up as an
> example, don't take this as a complete proposal, but just a way to
> sparkle discussion]


> There are a few important issues with the flowmap:
>  1) documentation must be provided on the FOM (flowmap object model),
> sort of a DOM for flowmaps. Currently, objects like 'cocoon', 'log' and
> others are provided, but there is no documentation presenting this

We should strive to have the *same* objects available to sitemap and 

>  2) mappings between java and javascript: I don't know how much coupling
> can be done between java and javascript in the flowmap, this must be
> documented more.


Just 1 tip:
on the Ant list I've seen that someone has made a javadoc system for 
Javascript, and it would be cool to have it used in flowmaps!
I'll keep you guys informed.


Last, I would like to thank Ovidiu for making the Cocoon Flowmap in the 
first place.
He kept coding even when it seemed hopeless to many of us, and now we 
have a real killer app.

Thank you, thank you, thank you :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message