> > 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. 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. In my webapp I have a lot transactional stuff,
trys/catchs and lookup stuff. So writing these things in Java is
natural for me.

If I think of a Flow, which connects pages and combine actions, then
the FSM is the first solution, which comes in my mind. Everything else
twisted my thinking. I have learned enough languages in the past to
know what I like and what not.

My 2cents, Stephan.

Reply via email to