On Monday, Jul 14, 2003, at 05:32 America/Guayaquil, Stephan Michels wrote:
You must think of it as the JSPGenerator and the JSPReader. Why use
JSP in Cocoon when we have these powerful XML pipelines, XSP, etc ?
Simply because we're not alone in the world, and because other people
want to use Cocoon, but don't want to trash all what they know and did
for that.
wait wait wait: if you are talking about connecting legacy stuff to the
current flow handler, I'm sure you can do it in just a few lines of
flowscript. Legacy connection is *not* a good point here.
As Leo said: instead of allowing multiple implementations *just because
it's cool*, have people present their problems that can't be solved
with the current implementation.
I haven't seen this happening. I've just seen arguments like "my customer doesn't want to write javascript" or "I'm used to state transisions and I like them more".
These arguments do reflect reality (granted), but they don't show a reason for abstraction and don't back up the dangers of increasing the mutation rate of our code so dramatically.
[NOTE: if your customer dislikes to write javascript, use something like BPEL4WS (http://www.oasis-open.org/committees/download.php/2046/BPEL%20V1- 1%20May%205%202003%20Final.pdf) and XSLT-transform it into flowscript using an internal pipeline in the <map:script src="">.]
My point is: absraction in some key areas might prevent discussion (like this one) and might prevent ideas to be exchanged (like the above, which might be totally damn or genial, I don't know [kudos to Chris to pointing me to BPEL4WS, BTW]
All JavaScript Code can be transform into Assembler, or Basic. That's not the point. A programming language should make the implementation of a solution for a given problem as easy as possible.
A scripting language for a flow description is, IMNSHO, the most natural way to describe it (see below why)
In the direction the people prefer Basic over Assembler, and later Pascal/C over Basic. My problem with the current flow implementation is that is does not make my life easier.
You said you haven't even tried using it.
In my webapp I have a lot transactional stuff, trys/catchs and lookup stuff.
Which are entirely possible with the current flowscript.
So writing these things in Java is natural for me.
All java programmers tend to think at javascript as the "poor man client side shitty version of java". It's not. It only has a very unfortunate name and a very unfortunate history of object model inconsistencies between interpreting environments. But the language is *extremely* well designed and balanced, must more than it appears at first sight.
If we were talking about Scheme, well, I would agree with you: the mindset requires to use scheme are very different from those of java. That's why I questioned Ovidiu's first implementation. But javascript, god, it's java--+ where that -- reflects things that are removed and normally get in your way during flow description (compilation, strong typing) and + things that are added to help you out (tons of syntax sugar, weak typing, reduced verbosity, functions as first class objects, access to object prototypes).
Everything else is exactly the same and, BTW, we promote the use of java components for all the serious stuff, script has to be used as glue only.
If I think of a Flow, which connects pages and combine actions, then the FSM is the first solution, which comes in my mind.
Of course. That's exactly why GOTO was implemented in programming before understanding that you didn't need it.
But now it's a sin to even thinking about having it.
I believe that the concept of FSM has made unnecessarely harder to write web applications than it is to write, say, command line applications. People tend to think this is due the very stateless nature of the web. I disagree. I believe it's just because there were no web technologies out there that aren't based on the FSM approach. And people tend to think at this approach as the most natural, so they don't even try thinking differently.
But, if history repeats, it will take a few decades to understand that "FSM for the web are to be considered harmful". So I don't expect everybody to buy it right now. I'm patient :-)
But as long as you allow yourself to have "scripting preventing you from looking into the flow" you are locking yourself out. You might be preventing yourself from further simplifying your life. Up to you, but think about it: what do you have to loose?
It reminds me of those people I meet that say they will not use Cocoon because it doesn't promote official J2EE practices.
Those comments used to piss me off.
Now I just smile, sitting very relaxed on the side of the river, waiting for their dead bodies to pass by ;-)
-- Stefano.
