On Mon, 14 Jul 2003, Geoff Howard wrote:
> As I understand it (and intend to use it) the flow is not supposed to be
> actually performing the heavy lifting of your business logic, but
> "glue"ing it all together. You can do any transactional handling in a
> real java class which is then called by a simple flow. Does that meet
> your need?
No, it doesn't. Yes, I can write extra components which handles the
difficult stuff, and glue them together with 3 lines of JavaScript.
But at this point, the easiness of JavaScript is obsolete, and makes
the thing more difficult.
And I don't like temporary solutions like using servlet filter to
close my transaction.
But thank you ;-)
The real problem is that you have in the current Javascript implementation
an executing of a function over serveral page, which can cause timeouts
if you have open transactions, for example.
tx.begin()
sendPage(A)
tx.doSomething();
sendPage(b)
tx.doSomething();
tx.commit();
This is not good pratice, moreover it's dangerous. If you use method
between the pages, you doesn't came on the idea to write this from above.
page A
doActionA()
page B
doActionB()
doAction()
{
tx.begin
tx.doSomething();
tx.commit();
}
And also the ATCT solution not a good pratice in my eyes, because
you can also get the idea that the first snippet work.
So in POV, the best solution for me is some kind of FSM in XML,
which uses 'cut down'-Actions(without redirector), which the continuation
concept.
This will not be a problem until we decide to focus on a javascript-only
implementation.
Stephan.
> Stephan Michels wrote:
> > Hoping I'm not too late. Please interpret this not as personal attack
> > or something else. I like the idea of the flow, but the javascript
> > implementation inhibit me to take a deeper look into it.
> >
> ...
>
> >> +------------------------------------------------------------------+
> >> | JavaScript Interpreter |
> >> +------------------------------------------------------------------+
> >>
> >> [H] Our first and currently only[5] interpreter implementation is
> >> a Javascript implementation based on Mozilla Rhino which
> >> has been extended to support continuations.[6]
> >
> >
> > It just one solution. I don't like javascript, and the impression
> > that all can be handle harmless in one Javascript function is
> > dangerous, see handling transaction(hilbernate).
> >
> > I would love to see an alternative implementation.
> >
> > In my POV the flow belongs to the core, but not the javascript
> > implementation.
