I followed the thread about your workflow (or pageflow) proposal. The issues you are trying to address look pretty similar to the issues the Struts Workflow Extension addresses (which maybe should better be called Struts Pageflow Extension as well). It can be found at http://www.livinglogic.de/Struts/ .
Both frameworks try to make struts applications more robust by introducing well defined paths a user is allowed to step through the application. Given the significant overlap, it would be a pitty to see another extension being devloped in parallel. IMHO it would make much more sense to build on the base that is already there and improve it in those directions that are not sufficiently addressed yet.
What do you think? Is the existing extension too far away from your concepts?
--- Matthias
[EMAIL PROTECTED] wrote:
We should probably be calling it pageflow instead of workflow, simply because it is built around the struts controller and is not intended to fulfill workflow functionality (though there are some similarities). I built the pageflow add-on to do what Struts does, but just make it a little easier and more flexible for the developer. That is there are really no new concepts here, just a natural progression of Struts functionality. A pageflow is essentially what you get when you connect multiple Struts forwards to multiple Struts actions, my framework just formalizes the notion. The ultimate question in my mind is whether or not a web application can ignore information in the session. Pageflow is essentially a state machine. It expects the user to progress through the path that the developer planned. All of the struts applications Ive seen work essentially the same way. In some cases Vic is right, we have to program defensively so that if the user leaves the site and comes back, or progresses down a path the developer didn't expect, the site should still respond properly. However, pageflows can be developed this way as well. I will admit, pageflow is currently more susceptible to this issue that Struts 1.1, but I think we can fix most of that. One additional note, how many web applications let users jump in and out at a whim and still function properly? Most of the internet and intranet apps ive used (even ones programmed in struts) don't allow that. For example, I bank online, but if I hit the back button, the application tells me that the page has expired, probably because it would mess up the apps state to allow arbitrary navigation. As a matter of fact it has been the standard on most of the intranet apps Ive seen to completely disable the menu bars in the browser so the user couldn't hurt the application.
-----Original Message-----
From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Sunday, August 03, 2003 1:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Workflow for Struts
Ted Husted wrote:
The thing I keep coming back to is whether workflows are a Struts problem."
Agree! that Workflow, PageFlow are not a Struts... or a problem.
In greenscreens(Cobol), we had (work)flow, chose menu 1-12, then 1-6, etc. The programers is in control of next step.
Web is event oriented. The user is in control, programer has to code defensive. We just receive events and handle.
Ex: User start to fill out credit info, then browses to Amazon, Google, then comes back.
From business side, being process centric is bad. Info, or model, or data centric is better, since the business process changes and needs to be dynamic.
my 02 c. .V
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
