Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Message-ID: <3F2E1995.80403@livinglogic.de>
Date: Mon, 04 Aug 2003 10:30:13 +0200
From: Matthias Bauer <Matthias.Bauer@livinglogic.de>
Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Struts Developers List <struts-dev@jakarta.apache.org>
Subject: Re: Lets call it pageflow for Struts
References: 
 <C885B0E8B829BF41983891D17FABD08501FD391B@ausx2kmps307.aus.amer.dell.com>
In-Reply-To: 
 <C885B0E8B829BF41983891D17FABD08501FD391B@ausx2kmps307.aus.amer.dell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


Paul_T_Smith@Dell.com 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:vic_cekvenich@baseBeans.com] 
>Sent: Sunday, August 03, 2003 1:16 PM
>To: struts-dev@jakarta.apache.org
>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: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org