Hi Ramon,
See interspersed comments below.
"Felciano, Ramon" wrote:
> Hi --
>
> I'm evaluating Struts (+Turbine+Rocks) as a framework for our web apps
>
> We often want to insert certain UI actions based on exceptional user
> behavior. A simple example is an authentication screen that gets inserted
> "just in time". For example, if the normal flow of control is from page A
> --> page B, where page B requires authentication, then 98% of the time, the
> user goes A --> B. However, the very first time this happens we want to
> insert an authentication page: A --> Logon --> B. Other situations where
> this type of intermittent insertion of additional UI and flow logic would be
> helpful include:
>
> - Confirm pages ("Are you sure that xxxx?" with "Continue" and "Cancel"
> buttons)
> - Pick lists ("We couldn't find the product ID you entered; please select
> from the following list")
> - Alert pages for (possibly unexpected) server-side events that occured
> since the last client-server traffic passed through.
>
That is an interesting approach.
>
> I realize that these can all be implemented on a case-by-case basis, with
> each Action class deciding whether to insert a new flow element or not. A's
> Action class could check the authentication state and decide whether to go
> to Login or B accordingly. In the pick list example, this could be done by
> returning the user to the original form and using JSP logic to notice the
> error and display a list of options to choose from. However, if the page is
> a complex one, displaying a specialized form for just this input value can
> be useful.
>
> I guess I'm wondering whether there is any generalized support for this that
> might better separate the nature of these exception events? For example, in
> the login example, it doesn't make sense to me that A's Action class make
> the decision as to whether to show the login form, since the authentication
> is bound to B. In particular, I'd like to be able to reroute to Logon when
> needed, but otherwise continue with the "normal" flow of logic. Thus, if at
> a later date the "normal" flow of logic dictates A --> C, I only want to
> change this in one place (A's success forward property), and still benefit
> from the just-in-time authentication. Same thing for confirm pages, etc...
>
Within Struts 1.0, an approach to handling these things generically would be to
subclass the ActionServlet controller servlet, and override a method like
processActionPerform (which actually calls the selected Action) or
processActionForward (which forwards control to the returned logical page
name). You could then inspect the current state of the world, and inject
flow-of-control changes like this while still utilizing the superclass's basic
functionality.
To make the types of things you inject somewhat configurable, you might also
want to use your own custom ActionMapping subclass, with extra bean properties
that describe (to your override method) what exceptional things to do and when
to do them -- the selected ActionMapping instance is made available to most of
the processing calls, so this information would be easily accessible.
In future versions, one of the directions I really want to look is a more
"workflow" like organization of processing within Struts (both for the basic
processing that the controller servlet does for you, and for letting you glue
together finer grained tasks, in addition to (or instead of) the relatively
coarse grained Actions that are currently supported. Doing the sorts of dynamic
flow-of-control changes you are talking about would seem to fit into that model
pretty well, especially if you could "script" them in the struts-config file.
>
> Finally, and on a different topic, can someone please point me to the most
> recent discussion (or docs) regarding how to do Form validation with struts?
> The [outdated?] user guide first suggests not doing it in the ActionForm
> class, then provides a ValidatingActionForm that seems to encourage the
> practice...
>
The user guide is under active development to bring it up to the 1.0 APIs -- I
would expect the version you get with tonight's nightly build to be pretty up to
date.
On the particular issue of validation, the ActionForm class (you don't need
ValidatingActionForm any more) has a method:
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request)
that is used for form beans that want to validate. You return null if no errors
are encountered, or an ActionErrors object that is a collection of error message
keys (along with the field names the errors are assocaited with).
>
> Thanks in advance for your time.
>
> Ramon
>
Craig McClanahan
