cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 20:21:37 GMT
Sylvain Wallez wrote:

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

That's exactly the same experience I had: people simply say "c'mon it
can't be that easy"... well, it general it's not but the good old
"simple things should be simple and hard things should be possible" not
only applies to Perl :)
> >[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 :(

I'll comment this tomorrow afternoon :)
> > 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?

Good question: I really don't know. I would keep the basic anti-FS
pattern: do it only when you need it, not because it's symmetric.

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

Nah, flowmaps are not components anyway.
> > 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)"/> ?

Ok, this is a good point.
> >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 tend to agree here: it's just another contract you have to learn to
make this work. In fact, writing webapps *is* inherently more complex
than writing command line apps anyway.
> >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.

Ok, great.

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

yes, sorry :)
> > 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.

Great to hear. Anyway, let's keep these up high in the flowmap Todo
list. (would you or Ovidiu care to write one?)

[skip the 'detachable pipeline' concept] 

> The only thing to say is : Way cool !

If continuations will make the flowmap shine, detachable pipelines will
skyrocket cocoon component reusability into orbit!
> > 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.

No, no, no. Careful here:

 flow logic != business logic

I hope this is clear to everyone.

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

Most absolutely! Just like the sitemap is a way to compose your
xml-processing components, the flowmap is a way to glue your business
logic to drive the webapp flow.

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

Good point. Maybe we need an 'avalon' object in the FOM.
> >                              - 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 ?

Thank you much for asking this question.

Yes, I would dare to say so.

In fact, I use my own definitions of flow and workflow:

 - flow: a description of the sequences of actions that happen between
subsequent user interactions.

 - workflow: a description of the sequences of actions that happen
between subsequent interactions of more than one user.

In short: flow is about one user, workflows are about more than one user
(otherwise, they become flows again).

The flowmap was implemented to describe flows and since workflows are a
bigger set than flows, it is not automatic to think that a flowmap would
be able to describe workflows as well.

But I have the perception there are no design obstacles to make this
happen, as long as we provide a way to save the state of a continuation
persistently or at least set a pretty long expiration time (this is
probably something that will be connected with the 'continuation' object
in the FOM)

This said, it is *NOT* sci-fi to imagine a visual workflow editor being
able to create a sitemap, a flowmap, a bunch of views and auto-generate
a cocoon block for you to deploy in your running Cocoon.

It might be years away, I know, but it will be possible.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message