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 16:07:20 GMT
> Piroumian, Konstantin wrote:
>
> <snip/>
>
> >>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.
>
> Careful here.  You have to use the right tool for the right job.  If you
> were to propose EJBs as a flow control layer for a webapp, most veterans
> would think you are nuts.  You should never force a transaction to occur
> over the wire simply to find out where to go next.

Agree.
In our case the EJB layer is not for only controlling the flow, it also
hides the business logic needed to make the decision on where to go next and
also it interacts with the Workflow engine. Another requirement to our
system was that the user should have persistent states - you can
logout/timeout or even the web server can crush but you won't lose your data
and next time you'll b back to your last state/screen.

Also if you have to perform more than one business operation over the wire
to find out where to go next, then you'll see that sending just an Event to
flow controller is much effective - all the logic calls would be performed
on the EJB layer and you'll get the result containing the current state with
params. The only transaction over the wire would be sendEvent() call.

Maybe our case is too specific to be taken into account, but it has quite
good SoC: the presentation layer knows only how to display different states
and how to translate requests into Events to flow controller. And knows
nothing about the business logic behind the flow controller.

>
> As to using a "Component" to do the work, we already have the proper
> granularity.  I.e. Schecoon.  Currently we have Actions to help control
> flow, and we have Matchers and Selectors.

Yes, that's true. We've been using actions to interact with the flow
controller. So, why do we need another language to describe the flow? Why
not Java?

It will only make Cocoon more frightening to new people. I'm not a newbie in
Cocoon, but even I am tired of revolutionary changes in it (C1 - C2 - .. -
[C2 + Schecoon - Actions]), lack of documentation, etc. and it's going to be
very hard to convience other people even to try it.

>
> Schecoon was started as they do not represent intuitive and useful
> control layers for a webapp.  That is why the Avalon Component thing
> isn't going forward any farther than it already has.

Do you think that Schecoon is more intuitive? It's just another programming
language.

>EJBs are for macro
> scale transactions that you perform on your system.  You use them when
> you determine you have a need for them.  You do not have a need for them
> if all you want to do is control flow from one page to the next.

This is true only for simple cases. What if you need a distributed flow
control, persistent flow state, multiple applications using the same flow
and everything interacting with a WFMS?

Our implementation uses interfaces and is wrapped into web-server-side APIs
(base actions and helper classes), so you never knows where is your
controlling level implemented: is it an EJB or a Cocoon component or simply
an object in users session.

>
>
> > 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.
>
> :/
>
> Keep in mind who is writing the code.  Not all programmers trust visual
> editors.  I for one judge them guilty of writing poor code until they
> are proven innocent (opposite of American justice, but using them has
> made me a cynic).

Again agree, but we also had such requirement: the screen flow and forms on
the screens should be configured without need to program anything, e.g.
using a special visual tool. All the logic is implemented in business
components (they are also session and entity beans) and the flow can call
their API methods to perform it's logic. If something needs to be programed
then it must be done on the business layer.

>
> Also, the full Java language is too difficult to express in a simple
> script environment.  What about using JavaScript?  You only have to
> support certain models, and many web programmers are familiar with it.
>

Can JS provide means to call business logic from it? Simple cases are easily
expressed in XML-based script. (I would send you a real sample, but it's
prohibited in our company).

> All we need to do is provide a bridge for Scheme continuations to the
> JavaScript interpreter engine....

I'm not familiar with continuations, will look at them when there will be a
sample for Scheme.

>
>
> > 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" />
>
> We currently have the ability to choose our Sitemap implemenation
> directly.  Whether we choose the original sitemap layout, or we mount a
> flowmap directly in its place doesn't matter.  All that matters is that
> requests go in and responses go out.

I would like to have a possibility to choose the flowmap implementation and
not the whole sitemap. Current sitemap is quite good for me to implement
anything I need and the only thing to improve is action/action-sets and
cleanup/stabilize the syntax. This is my opinion.

Konstantin

>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> 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