On 14 Jan 2004, at 17:58, Ralph Goers wrote:
To add my two cents, FWIW...
We chose not to use Flow for the same reason we don't use XSP or JSPs; it is
too easy to start adding business logic where it doesn't belong.
True, but as I wrote right before this, with the compiling classloader you get the usability of scripting, the power of java and java-oriented editing, and your business logic is safely stored in your classes.
Ah, you say, how do I know?
Because between after the third time you write Package.java.lang.util.Hashtable in your flow you start feeling there is something wrong going on: the verbosity of livescript (the java-javascript connector) is a feature, not a bug... but the reason why people (me, for example) kept doing that was because the usability of non-compiled code was simply too great for development.
Now, with the compiling classloader, you get best of both worlds... and your code is much cleaner, and much more pleasent to write.
Actions
make it very difficult to perform business logic in the wrong place (i.e -
the presentation tier).
The only wrong place in the flow would be to have complex logic in the flow instead of having external components that do this. [if you are using jxtemplate, there is no way your logic ends up being in the presentation layer]
But as I said, I think we solved this problem.
-- Stefano.
