Matthias, Thanks for the reply. Sounds interesting. I wasn't aware of the workflow proposal. Of course I definitely want to share with whats out there. The only issues I see are scope of change. I originally went down the path of a new RequestProcessor and action type, but the breadth of additions I wanted to make, made that inefficient. For example, pageflows have the ability to edit, declare and use variables at any scope similar to JSTL. Have you downloaded the pageflow example? I will download the workflow extensions and see where we get some overlap. Could you do the same? Then we can compare notes. Paul
-----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 3:30 AM To: Struts Developers List Subject: Re: Lets call it pageflow for Struts Paul, 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
