cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 13:24:26 GMT
Stefano Mazzocchi wrote:

>Last time I wrote an RT about these things, the flowmap wasn't
>implemented. Today it's working, but there are things that I would like
>to change.
>
>This RT is to start a discussion that will hopefully lead to a coherent
>and community-driven design on what the flowmap engine will look like.
>
>First of all, since there is no clear howto about the current flowmap
>and I need to give you context in order to make you partecipate in the
>discussion, I'll write a basic explaination of what's going on.
>
>                              - oooo -
>

<snip what="presentation of the flowmap concept"/>

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

+1000 ! People to which I explain this at first don't understand it as 
it is "too much simple" : over the years, we have twisted our minds to 
overcome the limitations of the web infrastructure. But once they grasp 
it, they fall on the floor !


>This design not only makes it a breeze to implement MVC, but it shows
>you how natural and clear things become once you separate the procedural
>flow, from the declarative serving of resources.
>
>At the same time, I think there are a number of issues that we might
>solve before freezing the concept in a beta release:
>
>1) the semantics to call a flowmap from a sitemap are too implicit:
>users must assume to much from what they read (ie self-readability of
>the concept is very poor).
>
>2) the concept of continuations is not transparent, there is concern
>overlap between the view designers and the sitemap managers since the
>view designers must be aware of the URI location of the
>continuation-decoding URI.
>
>[NOTE: it is *not* required that you use continuations for your flow
>logic, you can use whatever means you have to control state as you did
>previously, such as REST-like passing style, sessions or cookies]
>
>3) there is currently only one way to implement the MVC "view" and that
>forces you to use XSP. This might not be a performance problem, but it
>might become a usability problem.
>
>Let's talk about each one of them independently.
>
>[NOTE: Giacomo and I spent a full evening and the next day (during
>"Italy vs. Mexico"! consider that!) talking about these things, so the
>above reflects design concepts of both of us]
>

Wow, so this is *really important* for you ;)
In France, we no more have this kind of problem :(

>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="http://apache.org/cocoon/sitemap/1.0">
>
>  <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>
>
>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 : flowmaps aren't resources and should be separated from them.

A side question : should flowmaps be inherited by subsitemaps ? While 
thinking of that, I was wondering if flowmaps should be declared in 
<map:components> since only components are inherited by subsitemaps.

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

-0.5 on this : it introduces some programming language constructs in the 
sitemap. And if this is allowed for flowmaps, why shouldn't it be 
allowed for other components as well, e.g. <map:transform 
type="xslt(use-parameters : true, use-browser-capabilities : false)"/> ?

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

That isn't so easy, as there can be many ways to pass the continuation 
id, and the example shows only one :
- as part of the request URI (as in this example)
- as a request parameter (from a hidden form field)
- in an XML document (SOAP webservices)

So IMHO, encoding and extracting the continuation id is the 
responsibility of the presentation layer and the sitemap.

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

You're not stuck to XSP : all the information produced by the flow will 
be stored request attributes. Note that I wrote "will" : for now Ovidiu 
uses the Environment object in a somewhat hacky way and we had some 
private discussions where I suggested to use request attributes instead. 
But this is still on the todo list.

>I'd like to have at least a few others:
>
> 1) XSTL
>
Typo for "XSLT" ?

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

We currently don't have access to request attributes from XSLT, but this 
should be fairly easy to implement, just as we already do for request 
parameters. Velocity and JSP shouldn't have any problem once they have 
the request.

>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.
>
>                              - oooo -
>
>Ok, almost there.
>
>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)
>
>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="http://apache.org/cocoon/sitemap/1.0">
>
>  <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!
>  
>

The only thing to say is : Way cool !

>[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]
>
>                              - oooo -
>
>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
>
> 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.
>  
>

This item has been discussed in the scope of performance, as we can't 
imagine writing the whole business logic in JavaScript. Rhino provides a 
natural interface to Java, and the flowmap should be considered as a 
continuation-enabled glue between various business logic components 
written in Java. Also, business logic can return Java objects that are 
held in flow script variables, and thus benefit from the continuations 
mechanism (provided they are serializable). So both worlds are 
complementary : the intrepreted flow script provides continuation 
support to compiled Java business logic.

What is missing in the FOM is the component manager that would allow the 
flowmap to have access to Avalon components.

>                              - oooo -
>
>Ok, please, send your comments.
>  
>

Some additional food for thought : continuations can be used not only as 
the driver for the interaction of a single user, but also for multi-user 
workflows. Consider e.g. a purchase order workflow : the emitter fills 
in a form, this form is then "sent" to it's manager that validates (or 
cancels) it, then to the purchase department, etc, etc.

All this process can be described by a global multi-user flowmap 
aggregating mono-user flowmaps that drive each of the individual 
activities. Since continuations can be serialized and archived, you 
could write a lengthy process (even weeks long) just as a simple 
sequential program that "goes" from one user to the other.

After revolutionizing webapp development, will flowmaps revolutionize 
workflow systems ?

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message