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 be
> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
