I can see from your response that this discussion has become adversarial , and I regret that. I remember, after Ovidiu, you were the first person to welcome me to Cocoon, and you have always seemed to have a good and positive attitude.
I don't like the tone of our recent messages, and I'd like to change it. Is that possible? My objections to the proposal you and Marc made were simply based on the fact that I feel like Cocoon is (finally) on the verge of realizing the vision Ovidiu introduced to it two years ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100715975517943&w=2
That vision was indeed based on continuations and programming languages as (later) reflected in the names of the sitemap elements. Maybe it's a small point but to me it seemed unnecessary to change that right now.
This may be subjective, but for me, the vision remains regardless of what programming language is used to depict the page flow. In Christian Queinnec's original work it was Scheme, now, in Cocoon, it's JavaScript. If we were to implement Brakes-based Java continuations it could be Java or Jython, etc.
However, I felt something was lost from that vision, for me anyway, with the proposed abstraction. That is why I objected to it.
Nevertheless, as you point out, other "visions" of page flow are possible, and I certainly don't want to discourage anyone from pursuing them.
Best Regards,
Chris
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
<snip>
Now, part of my job is giving Cocoon presentations and trainings, so I also talk about flowscript, continuation trees, the end of back-button infamy, etc. I always have a low of wow's and people find this very interesting.
And then, there are two categories of people :
- those who have no existing background on page flow problems. They have no problems with our way of doing it.
- those who have some background, either as code or as trained people.
People in the second category, after the mind blow is finished, ask me :
- "why use JavaScript ? I'm used to plain Java and don't want JavaScript".
Well, let's work on a Brakes/Java based flow engine that supports continuations. We can also use the Eclipse Java compiler to behave as a Java interpreter (see ftp://ftp.primaryinterface.com/pub/javacAPI) so that you get all the development-time benefits of a scripting language and still use Java and get code-completion in your IDE. This seems to me like a much better solution for such people, than reverting to a FSM approach simply because they don't want to use JavaScript.
I never said that I wanted to revert to FSM because people don't want to use JavaScript. What I said is that the current interfaces underlying the flow are too much oriented towards an _interpreter_ supporting _continuations_.
Now your proposal is exactly what I'm aiming at. But it ain't JavaScript, and as such has no place in Cocoon's CVS if we consider the community results that have been recalled clearly. Or are you ready to trash your Rhino-with-continuations in favor of having Rhino-generated classes augmented by Brakes ?
- "I have an existing backend" or "I use Struts". "How can I link it to the flow ?"
What should I say ? Use actions ? Use Struts as the toplevel servlet and Cocoon for the view (I did this once) ?
Well, I would say that it is very easy to convert a Struts app to use Flowscript. I originally converted the IBatis Petstore (http://www.ibatis.com), a Struts application, to the current Cocoon Petstore sample (with Velocity as the only view) in 1 day.
Sorry, Chris, you don't get the point : I also would be able to do that. But the problem is different : there are people out there (yes, customers) that *don't want* to do that. And this all where the whole problem lies.
Is "StrutsFlowEngine" really a viable approach?
It's not viable as something promoted by Cocoon. I never said the contrary. But it's more than viable to convince people to move to Cocoon without breaking all their existing code and knowledge. The latest Jakarta News says that Struts has the biggest user mailing-list with more than 2700 subscribers. What about attracting some of them to Cocoon ?
If so, why not put the code in the scratchpad to demonstrate it.
As you know that there is no such code, I don't know how I should consider this. As I'm an optimistic guy, I'll take it positively, as the scratchpad it the place for future mutations of the code base. So thanks for the offer.
Sylvain
