see interspersed comments below...
"Laird J. Nelson" wrote:
>
> ----- Original Message -----
>
> I like to think of this as the "dialog box problem" that web UIs face.
> That is, each case above, in a "traditional" client-server program,
> would be implemented, usually, as a dialog box. What's unique about a
> dialog box? It pops up and gets in the way of where you (a) are or (b)
> were trying to go. Only when you dismiss it are you "returned" to
> either (a) or (b). On the web, of course, with our primitive HTML-based
> UIs, there are no such things as dialog boxes (unless you use
> javascript). So "screen flow" becomes all important.
>
> I bring this up because struts seems to have gone partway--better than
> any other framework I've seen--but not all the way in its support of
> this dialog box metaphor (it uses form beans). What is now needed is a
> navigation stack of some kind--perhaps even something that is
> written/phrased in terms of "traditional" UI metaphors. I'm thinking
> about some kind of stack--and believe me, I haven't thought this all the
> way through yet--that can be accessed by Actions, but any given Action
> would typically say something like "OK, go to the next screen that I'm
> being told to go to, or if I'm not being told to go anywhere, go to this
> default location". Or the Action might be able to say "oops, conditions
> aren't right to advance; pop the stack and go back to where we were a
> moment ago but display the following message". Things on the stack
> would be *roughly* equivalent to screens--though I hesitate to use
> "screen" as I think that's one of the major shortcomings of the Turbine
> framework, because a "screen" on the web often exists as a separate
> entity only because the marketing department said it has to.
Actually, I've implemented just such a construct at work for the struts
based prototype of a significant financial web-application shell. There
was some discussion on this list some time ago about something called a
StateManager, which is essentially what this is. And yes, the concept
of
"screen" is fuzzy -- in my situation, a "screen" is really a [at times]
complicated and changing frameset.
The app/shell's flow follows a (process/state update/redraw) pattern
in a [con]federation of sub-applications (and thus, controllers).
See my attached diagram with numbered steps as follows:
1) Application Request
Client-side user triggers a request to the server.
2) Sub-application Controller Dispatch
Dispatches the request to the appropriate action handler.
3) Action Request Processing
The actions process the request, invokes relevant business logic,
sets up data and state beans.
4) Redirect Response
Initial request response is _always_ a redirect to a single URL
to redraw the application window.
5) Window Redraw Request
There is one global window redraw request handled by the main
controller servlet. This request "repaints" the entire browser
window based on the current state of the application.
6) Main Controller Dispatch
Dispatches the request to the appropriate action handler.
7) Action Request Processing
This sets up the request object and determines the correct views to
"forwards" to based on what's on top of the page stack.
8) Request Forwarded (dispatched) to Views
9) JSP Views Render Response
10) Final Result Response
Response to the redraw request.
(apologies for the detail level in these steps -- I lifted this diagram
and description from the system overview documentation I'm working on
at work (geared towards newbie developers in my group))
one side benefit of this indirected approach is that the application
has _total_ control over what the user sees...because all requests
_always_ result in a redirect to the same _global_ repaint action,
the browser's navigation buttons are effectively disabled; the user always
gets presented what is currently at the top of the pagestack -- be it
error page, form, interjected "dialog" window, etc. The framework
effectively hides the implementing JSP views from the browser's URL
location making it more difficult for the user to bookmark intermediate
pages or the browser to track page history (something which is usually
not desirable, especially with sensitive apps/sites).
I hope this was helpful...
e
--
_______________________________________________________________________
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Unknown Document
