"Frye, Dave" wrote:
> My second step was to define how requests are dispatched. IAF's Dispatcher
> dispatches requests as follows:
> 1. Log the request
Is this an application log for all the sessions?
Could you retrieve the history of a user's session from here at runtime?
"Frye, Dave" wrote:
> <Dispatcher>
> <Actions>
> <Action Name="LogIn" Controller="app.LogInController">
> <NextAction>ShowLogInSuccess</NextAction>
> <DisplayBean>app.LogInBean</DisplayBean>
> <Validation Parameter="userID" ErrorMsg="User ID is blank"
> Rule="NotNull"/>
> <Validation Parameter="password" ErrorMsg="Password is blank"
> Rule="NotNull"/>
> </Action>
> <Action Name="ShowLogInSuccess" Controller="PageDisplay"
> Arguments="/Login.jsp">
> </Action>
> </Actions>
> </Dispatcher>
Incidentally, while many Struts developers organize their config files
by type, you can also organize it by package, and also combine David W's
validate.xml into the struts-config.xml, giving you something like:
<!-- logon package -->
<struts-config>
<form-beans>
<form-bean name="logonForm"
type="org.wxxi.gavel.logon.Form"/>
</form-beans>
<action-mappings>
<action path="/logon/Enter"
type="org.wxxi.gavel.logon.Enter"
name="logonForm"
scope="request"
validate="false"
input="/WEB-INF/jsp/logon/Form.jsp">
</action>
<action path="/logon/Submit"
type="org.wxxi.gavel.logon.Enter"
name="logonForm"
scope="request"
validate="true"
input="/WEB-INF/jsp/logon/Form.jsp">
<forward name="success" path="/menu.do"/>
</action>
</action-mappings>
</struts-config>
<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required,mask">
<var name="mask" value="^[a-zA-Z0-9]*$"/>
<msg name="mask" key="logon.username.maskmsg"/>
<arg0 key="logon.username.displayname"/>
</field>
<field property="password" depends="required">
<arg0 key="logon.password.displayname"/>
</field>
</form>
</formset>
</form-validation>
... more <struts-config> and <form-validation> blocks ...
This approach would allow a configuration file for each package in your
application, so you could have Ant assemble them at runtime, as many
people now do with the application properties.
"Frye, Dave" wrote:
> My team did create a package that provided a sophisticated user, group,
> role-based security implementation that provided authentication for use when
> no other security existed, however, it is provided as an optional package.
Hmmmm ... (repeat) Hmmmm ...
> However, IAF is lacking a method (as explained by
> Matthias) for keeping track of where the user has been, so it is impossible
> to have call-return flexibilty. By call-return, I mean I would like to call
> the functionality of an Action from multiple locations, and when that Action
> is finished, I want to return to where I was called from.
Right now I'm considering using two mechanisms in tandem. One would be
an ActionForm stack, where you could park an ActionForm for future use.
This way if the flow branches or is interrupted you can get back the
interim state later. A centralized mechanism would help keep this
utility getting out of control and it could act as a cache (dispose
older items when newer were entered) to prevent overuse.
The other mechanism is some type of ActionForm listening. Here, an
object could register an interest in a certain ActionForm property, and
be alerted of its current state when it comes into context. (Of course,
this could be a subset of a larger event handling mechanism.) The idea
is that I could park an ActionForm on the stack, and have it be alerted
when other relevent ActionForms were accessed (created, read, or
updated). This could let the Form on the stack update itself with
related properties (foreign keys) that the user would otherwise have to
provide (client, vendor, product). Another use may be a master form to
collect properties from several sub-forms in a "wizard" workflow.
At some point, actions that might ordinarily return the user to a menu,
or some other "rest" state, could check the stack and automagically
return flow to the ActionForm's Action when present. Of course, a single
router action (or ancesstor method) could perform this service for every
relevant Action in an application.
Just thinking outloud ... comments welcome
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
