ActionMappings don't have names, but use an identifier that is
determined by the Action's URI. The URIs are virtual identifiers, but
they are not true logical identifiers. If the URIs much change for any
reason (e.g. the security scheme is modified), then all the JSPs that
refer to a mapping must be updated.
Elsewhere in the framework, we offer developers the opportunity to
choose whether an attribute refers to a "path" or a logical name,
examples being the input property of the ActionMapping and the formset
name property in the Validator package.
In the case of ActionForwards, we allow a logical name to completely
encapsulate a URI. This has been a useful feature and leads to the
cability to rearrange resources without editing JSP code.
We could offer the same flexiblity for ActionMappings by adding a
property that gives the ActionMapping a true logical name not coupled to
any other usage (e.g. a URI). Since the "name" property for the
ActionMapping is in use, I would suggest "actionName" be used to store
the logical name.
If other components in the framework can refer to the logical name, then
the path (which is coupled to the system URI) can be changed without
editing JSP code. Following the example of the IncludeForward, a
controller/processor property could indicate whether the "action"
attribute refers to the action.path or the action.actionName (the
default being "path" to retain the original behavior).
Other components, like the <html:link> tag, could be extended to allow
reference to the action property (along with forward and page).
Developers could then refer to the action by name, as we now do with
forwards. This is important, since the new best practice of passing
control through an ActionMapping can lead to teams defining both an
ActionForward and ActionMapping to represent a single entry point.
Given a logical reference to the ActionMapping, it becomes much easier
to use the ActionMappings as the primary entry point to an application's
feature set. The ActionForwards then devolve back to being the primary
exit point. Right now, since ActionFowards are the only logical URI
wrapper we have, there is a tendency to use ActionForwards for both
entry and exit points, a practice which may conflict with the orignal
design philosophy.
A common setup like this
<forward name="viewRecord" path="/record/View.jsp"/>
<html:link forward="viewRecord"> ...
can become
<action path="/record/View" mapping="viewRecord" forward="/record/View.jsp"/>
<html:link action="viewRecord"> ...
in the latter case, the link would resolve to $MODULE/record/View.do,
which would in turn forward to the destination resource,
$MODULE/record/View.jsp.
For a HTML form, we could have ActionMappings like
<action path="/record/Store" actionName="storeRecord"
type="app.Store.Record" ... />
and tags like
<html:form action="storeRecord"> ...
Note that we are using a logical name for both the link and the form
tags, and not a token that is coupled to a URI. If the URI changes for
any reason, say we want to secure some resources under /admin/*, we can
do things like this:
<action path="/admin/record/Store" actionName="storeRecord"
type="app.Store.Record" ... />
and not have to change any JSP code.
Of course, the roles property in the Struts 1.1 ActionMapping mitigates
this particular example. But the point that ActionMappings should have
independent identifiers still follows.
My short term plan would be to implement this scheme and test it with my
own applications before proposing an actual patch. Depending on other
events, this patch could be applied to Struts 1.1 (to finish what we
started in with inputForward) or held for Struts 1.2.
I suggest that as part of the post 1.1 Struts discussions, we might
consider an early release of a Struts 1.2 (weeks rather than months) to
catch many of the "later" items in Bugzilla. More aggressive changes to
the code base to leverage Servlet 2.3, later JVMs, and so forth, might
fall under the heading of Struts 2.x (or some sexy codename).
-Ted.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
