cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Sat, 23 Nov 2002 20:49:34 GMT
Torsten Curdt wrote:
> <snip/>
>>We must do *everything* possible to prevent abuse of the flowscript 
>>layer. In fact, at the Cocoon BOF, several people expressed this concern 
>>of seeing script kiddies coming from the flash world abusing the 
>>flowscript and making the whole thing unmaintainable.
> that's also one of my fears...

Andy expressed this loud and clear at the Cocoon BOF, but he (and many 
others that never touched javascript not even with a stick) have a hard 
time understanding that while Java is a platform (means language + 
libraries), JavaScript (well, should say ECMAScript) is *just* a syntax. 
The object model available for your scripting is totally dependent on 
the environment that interprets the script.

This is actually the major reason why DOM was created: to standardize 
the set of objects that are available from a page script in a browser 

So while DHTML is HTML + EcmaScript + DOM, FlowScript is EcmaScript + 
Cocoon Flow Object Model (FOM?).

This FOM is described in package 
org.apache.cocoon.components.flow.javascript and so far includes:
    - provides object 'Log' to the script
    - provides functions:
    - provides the object 'Cocoon' to the script
    - provides the object variables:
     - provides the object functions:
     - provides the object 'WebContinuation'
     - provides the object variables:
     - provides the object functions:

and, of course, the call-with-continuation methods sendPage*() which are 
added to the interpreting environment directly.

[ovidiu, we must make a serious effort to document this stuff or people 
will simply keeping on being scared of what the flowscript is. Since you 
are the man around that, I'd love if you could start at least filling 
the above skeleton with what is missing and what the calls are supposed 
to provide.]


>>>2. Dynamic Flow Loading.
>>>The way I see it, the flow controller managers the flow through a set of
>>>available "views" (pipelines in our case). However, its quite possible that
>>>in certain situations the flow through this particular set of views will need
>>>to differ. For example, the flow through the views for a user with the
>>>profile of "administrator" might be different than for that of "user".
>>Hmmm, -0.9 it sounds like overseparation of concerns to me (oSoC, it's 
>>anti-pattern brother). We *want* people to work on the same file, 
>>otherwise, the flow of the administrator and the one of the users might 
>>get out of synch.
> why should they have to be in sync?


> it might be a totally different
> flow.. 

yes, sure, but it smells like overseparation to me. Why don't we start 
with one and then see in the future what happens? I'm afraid of FS here.

> If we could read the flowscript from an internal pipeline we
> would be set.
>  <map:flow language="JavaScript">
>    <map:script src="cocoon://something/prefs.js"/>
>  </map:flow>

hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my 
head, but I have several great examples of where having that would rock 
the planet.... but still, I'm afraid of people going back adding 
programmatical logic to the sitemap....

... but it would be *so* cool to have a Workflow definition language 
created as markup and then having a pipeline that generates the 
flowscript by XSLT transformation!

I know, I know, it smells of FS all around, but this would make it *so* 
easy to be able to connect cocoon to existing workflow editing systems.

Gosh, I have to think about that.

What do you people think?

Stefano Mazzocchi                               <>

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

View raw message