Cool. I can help some there as I do the same with the Workflow Extensions.
-----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 9:22 AM To: Struts Developers List Subject: Re: Lets call it pageflow for Struts Paul, I will download your code and try to work into your concepts to see what is common and where our approaches differ. --- Matthias [EMAIL PROTECTED] wrote: >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] > > > --------------------------------------------------------------------- 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]
