cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [RT] Flowmaps
Date Tue, 18 Jun 2002 10:54:51 GMT
On Mon, 17 Jun 2002, Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:

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

Of course ;)

> In France, we no more have this kind of problem :(

I'd like to express my condolences ;)

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

Good point. I have not thought about it. My vision was that a flowmap
was coupled with *one* sitemap for its "views". I can't see what one
gains if the can make a general flowmap available to every sib-sitemap,
do you?

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

Stefano and I talked about it, too. My suggestion was to provide the
data as request attributes, too.

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

Think so.

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

Yup.

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

Yes, this would make CMS/DMS implementations much easier.

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

We also talked about having a Java implementation of the flowmap even if
we have to sacrifice continuation for that but can gain performance.

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

This is absolutely necessary I think.

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

This sounds very interesting. We need to take it in mind.

Giacomo


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


Mime
View raw message