Adam, I see you're point, though I think it may be easier to program defensively in pageflow than in the current struts. The reason is that how well you can predict what the application will do when a edge-path is used. In pageflow, variable handling and flow control can be explicit (i.e. declared in the control file). It is perfectly possible, even easy to tell the engine that the user may exit at different points and that it should be ready for that. As a matter of fact the pageflow engine is implemented as a state machine and could be built to allow branching at any user request. An interesting approach to this might be an inferencing process based on a tool like DRULES to control how you want the engine to handle the situation. That's actually a VERY cool idea. Pageflow has a task called HandlePageRequest that could look up a rules engine based on customizable rules and do whatever it finds there. This way individual companies could make the engine respond the way they wanted without having to customize the struts engine. Paul
-----Original Message----- From: adam kramer [mailto:[EMAIL PROTECTED] Sent: Sunday, August 03, 2003 2:07 PM To: Struts Developers List Subject: Re: Lets call it pageflow for Struts On Sun, 3 Aug 2003 [EMAIL PROTECTED] wrote: > 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. > IMO, this is weakness of most formwizard/page flows in webapps on the internet. The ability to jump around within pageflows may be needed by the overall business reqs. In my experience developing intranet apps, there were situations where the flow of forms couldn't be predicted or formalized (only given a "normal"/best-case pageflow), but all the forms had to be tied together as one functional "workflow". I definitely agree with Vic as well about programming defensively. If pageflows was robust enough to arbitrarily allow teh user to move about when deemed necessary, this would be a great advantage for many users. -Adam K. --------------------------------------------------------------------- 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]
