struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Lets call it pageflow for Struts
Date Sun, 03 Aug 2003 19:45:27 GMT
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. 

-----Original Message-----
From: adam kramer [] 
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 wrote:
> One additional note, how many web applications let users jump in and out
> 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
> page has expired, probably because it would mess up the apps state to
> 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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message