cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <>
Subject Re: [Schecoon] flow control layer
Date Thu, 28 Feb 2002 12:56:30 GMT
Piroumian, Konstantin wrote:
>>Hi Ovidiu,
>>>Hi Maciek,
>>>Yes, that's right. Using inner classes you can implement
>>>closures. Once you have closures, you can implement continuation
>>>passing style (CPS) very easy. Furthermore, any program written in a
>>>language with direct continuations can be translated in a CPS program.
>>>Nevertheless, I think program in a language with first class
>>>continuations is much easier to read than the equivalent CPS program.
>>Sure. That is why cocoon need a flow language. What I want to stress is:
>>it is
>>possible to implement flow language direcly in java without scheme layer
>>(despite my great enthusiasm for functional languages), and, as You have
>>already pointed, it is possible to implement it easily.
> The description language of the flow can be done in XML (in terms of
> <state>, <transition> and <operation>), but the implementation can
> different: Java, Scheme, JavaScript or even PL/SQL. I would prefer someting
> like this:
> A sitemap (+subsitemaps) - URL map responsible for matching requests to
> processing pipelines
> Flowmap(s) - flow processing descriptions, that can be plugged to processing
> pipelines, like actions and action-sets
> e.g.:
> <!-- This is the request handling logic -->
> <match pattern="registration/input">
>     <flow src="registration.xmap"> <!-- Perform input processing -->
>         <forward name="{success}"
> resource="registration/next?state={current-state}" />
>         <forward name="{error}" resource="registration/error" />
>     </flow>
> </match>
> where 'id' attribute is one of the possible results of the given flow. This
> is the same as Struts' flow processing.
> <!-- This is the output logic -->
> <match pattern="registration/success">
>     <act /> <!-- E.g. select a skin for the current user -->
>     <generate />
>     <transform />
>     <serialize />
> </resource>
> Struts has simple, but very useful concept of input processing, but it lacks
> Cocoon's publishing power. For me, the perfect solution would be Struts +
> Cocoon tandem, where the flow is controlled by Struts and output is
> performed by Cocoon.

Given the choice, many people might prefer something like the above, so 
I guess we should allow a little freedom and modularity (although 
personally I would probably use a real programming language as the flow 
processing logic can easily get quite complex).

I suppose we could eventually have something like:

implementation: Interpreted Scheme / Full Java / BCEL'd bytecode / ...
    translation: ------------------------------------------------------
         syntax: 'FlowScript' / XML 'FlowMarkup' / ...
    translation: ------------------------------------------------------
         syntax: Simple Custom Markup / ...

But I would first like to see a single usable implementation that can 
adequately show the concept.

(: A ;)

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

View raw message