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]

Reply via email to