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.
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.
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. 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.
> 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).
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.
All we need to do is provide a bridge for Scheme continuations to the
JavaScript interpreter engine....
> 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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
