Yes, I've brought this up a couple of times in the past.
First, I tried to use the sitemap as the flow controller for my business
logic. This worked fine for small and simple things. However, when the
page flow turned into anything of any substance it quickly became
unworkable.
I then looked at javaflow. I liked it because it was Java. But I also
hated it because it was Java. Managing the application flow through a
programming language just makes for something that is still pretty messy
but it is hard to change.
My one adventure into flowscript was quite by accident. A coworker used
one of Cocoon's sample calculators in a website. After the release went
live threads started looping periodically. After reviewing dumps I
discovered that Rhino was causing the loop. As it was virtually
impossible to figure out what was causing the problem we pretty much
decided flowscript was not such a great idea. Secondly, it really isn't
that much better than Javaflow in terms of being hard to change the flow.
We've been developing some of our applications using JSF. While it
isn't all that bad, when I compare it with Spring WebFlow I find I just
like the way it works better. Since we wrap all of our JSF portlets
with Spring anyway it just seems to make more sense.
Finally, I've always felt that Cocoon's strength was as a View
generator. I could never recommend that folks use some of the blocks as
they are huge security problems are horribly clumsy ways to access the
business data. That being said, as a View generator Cocoon is
fabulous. So to me, since 2.2 is already Spring based it just seems
that providing support for integrated WebFlow makes a lot of sense.
Ralph
Torsten Curdt wrote:
I really, really want to integrate Cocoon with Spring WebFlow as I
feel that that is a much more workable solution than trying to build
applications using flowscript or javaflow and this only really makes
sense with 2.2 since it is Spring based.
You brought this already a couple of times.
Years and years ago (when I was still working at dff) we developed a
xml based flow engine way before what we call flow these days existed.
It was so horrible to maintain that we dropped it. Maybe just the lack
of tools ...or maybe just the lack of resources writing those tools
...but I am still afraid when ever someone pushes into a similar
direction. There was also a talk at FOSDEM about such an approach and
I only barely could hold back to comment during his talk ...he was so
excited and convinced about the solution. For us just a minimal flow
resulted in so much xml ...bah! Make sure you evaluate it's what you
really want before you go down that road.
Just my 2 cents
cheers
--
Torsten
