cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: [Schecoon] flow control layer
Date Tue, 26 Feb 2002 14:03:52 GMT
<skipped>
> I think the finite state machine approach is difficult to extend to
> complex sites. It is very difficult, and rather limiting, at least for
> me as a programmer, to think the application as a finite state machine
> only. Any time I need to introduce a new state in my application, I
> have to reconsider all the transitions to that state, and the impact
> it has on the existing system.

Yes, that's true. It's quite difficult to support large sites with a
state-machine like descriptions, but for web apps that are using a lot of
forms and have a little publishing this approach can be very useful to
control user actions. We are using something like this to describe the flow
of application:

<flow>
    <state id="first">
        <on-enter>
            <exec operation="OnEnterOperation">
                <param name="user" value="$currentUser" />
            </exec>
        </on-enter>
        <on-event name="insert">
            <exec operation="ValidateInsert">
                <param name="input" value="$userInput" />
                <result id="isValid" />
            </exec>
            <if test="$isValid">
                <exec operation="PerformInsert" />
                <goto state="second" />
            </if>
        </on-event>
        <on-exit>
            <!-- Perform on exit operations -->
        </on-exit>
    </state>
</flow>

The handler of this is implemented as a Session Bean and can be used from
whatever application you like be it based on Struts, Cocoon or something
else using special flow controll actions.
In our application, the user can have multiple started flows and can switch
between flows (either implicitly or explicitly), e.g.: the system operator
can start multiple registration flows and work with them independently, even
using multiple browser windows.

The Struts/Cocoon actions just translate requests to events + data and call
flow controller to perform the logic. Controller returns the current state
and processing is forwarded to the handler of the current state, e.g.
another pipeline that displays the current page.

>
> I'd be more happy if I can describe the flow in a "normal" programming
> language, where I can express complex flow by writing a program. This
> is what I'm trying to do in the Schecoon sub-project. Using the Scheme
> language, and the fact that continuations are first class objects in
> it, I want to implement the ideas described in the resources I
> mentioned earlier. But the language to describe the flow will not be
> Scheme, but one with a more familiar syntax.

Maybe Java? ;)
Why not use EJB (Session Beans) or something similar to them (e.g. custom
Avalon components) to control the flow? You can implement *anything* you
want in Java. The reason that we don't use Session Beans as-is, is that it
would have a lot of similar code.

Our flow syntax is quite simple, but powerful and it's possible to describe
most of the flow logic with it (the rest can be processed using custom
operations that are implemented in pure Java). And another goog thing is
that the flow language is XML and thus a visual editor can be written quite
easily.

I've been also thinking about adding extension mechanism (something like
transformers/logicsheets) that would allow to add custom handlers to our
flow script and an idea came to me: maybe flow controll can be plugged to
Cocoon using sitemap logicsheets? In that case nothing is changed in Cocoon
core and everybody can have the flow controller he needs/likes.

Just my <i18n:currency value="0.02" />

Regards,
    Konstantin Piroumian

>
> Best regards,
> --
> Ovidiu Predescu <ovidiu@cup.hp.com>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

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


Mime
View raw message