You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2006/08/23 07:05:32 UTC
1.3.x: Action Aliasing
When I got my "WebWork In Action" book, I saw it had the ability to give
names to actions. This feature I wanted in Struts 1.x because my action
paths are usually 3-5 directories deep in a command-like pattern. I find
it very very difficult to keep my action configs, forwards, and JSP tag
use all in sync. You wouldn't believe it, but I also change my URIs
during development quite a lot and it is a management challenge to make
sure everything that should be changed, is.
So I wrote the code for myself and want to add it to SVN, but not
without first getting opinions on the idea. I have added an "alias"
attribute to the action mapping, which is recognized in forwards and the
tag libraries to refer to action mappings under a symbolic name.
Here's an example:
<action path="/member/person/account/load"...>
<set-property property="alias" value="loadAccountAction" />
<forward name="success" path="editAccountAction"
redirect="true" />
</action>
<action path="/member/person/account/edit"...>
<set-property property="alias" value="editAccountAction" />
<forward name="success" path="editAccountPage" />
</action>
Here there are two actions aliased editAccountAction and
loadAccountAction. Because I use Tiles, you also see an editAccountPage.
Notice how you can symbolically forward to an action, just like you can
a Tile. Likewise, in a JSP, you will see <html:form
action="editAccountAction">, and the same for <html:link>
I ate my own dog food and put this into an almost-ready production 1.3
app and it works out great. I can now localize all my URIs to the action
configs themselves, and refer to everything else symbolically. This
works even with ActionRedirect parametrization. I also tested with
modules. I also back-ported this into the old RequestProcessor. I very
much wanted this feature myself, so I want to commit it unless there is
a serious objection to it.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pb...@apache.org>.
Ted writes:
>>
I'm thinking of proposing class aliases for XWork 2, where we could
give an internal logical name to FQNs. Then in the class (or type)
element, we could refer to the alias rather than the full package and
class name. Since the term "alias" was taken, my thought was to call
these element "class-ref".
>>
Has ibatis spoiled you? :-) I love that feature and wanted to take it as
well.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Ted Husted <hu...@apache.org>.
On 8/24/06, Craig McClanahan <cr...@apache.org> wrote:
> The other approach, if you're using something like Digester (which is true
> at least for S1) to parse the config file, is to define an explicit rule
> that calls the right setter if there is an attribute with a specified name.
We do the same sort of thing in Struts2/Xwork2. The
ValidatorFileParser looks for the "short-circuit" attribute and uses
it to set the ShortCircuit boolean property.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Craig McClanahan <cr...@apache.org>.
On 8/23/06, Paul Benedict <pb...@apache.org> wrote:
>
> Ted Husted wrote:
> > Use "action-id" then. The point is that moniker "alias" is going to
> > cause confusion, since it already means something entirely different
> > within the Struts 2 community.
> Right now attributes are squarely mapped to properties. Java does not
> allow dashes in a property name, so what is a workaround?
One way to deal with this would be to provide your own BeanInfo class that
defined a property named "action-id" with the getter and setter methods
that you want to use. That way, the JavaBeans introspection logic would use
your setter method, instead of not recognizing this as a property. But
that's likely to be too painful for this kind of use.
The other approach, if you're using something like Digester (which is true
at least for S1) to parse the config file, is to define an explicit rule
that calls the right setter if there is an attribute with a specified name.
Craig
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pb...@apache.org>.
Based on everyone's recommendations, I am going to try "action-id" as
the attribute. I couldn't find it in the source, but isn't there some
Digester config file I can modify? Or not.. Is it done explicitly in the
ActionServlet? It looks like it, but I'd like some verification on this.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Martin Cooper <ma...@apache.org>.
On 8/24/06, Paul Benedict <pb...@apache.org> wrote:
>
>
> Why not just call it actionId instead of action-id? Done.
>
> I gather from the names we choose, most of everything is lower case. It
> could just be a style objection -- certainly not a content objection.
I'm not sure what all you're including in "most of everything". It's
certainly the case that we use lower case with dashes for element names, but
attribute names are camel case (at least in part because they will then map
to JavaBean property names). The action id is neither of those - it's an
attribute value - but I think that would make it OK to use camel case there
too, and for the same reason. ;-)
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pb...@apache.org>.
Why not just call it actionId instead of action-id? Done.
I gather from the names we choose, most of everything is lower case. It
could just be a style objection -- certainly not a content objection.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Martin Cooper <ma...@apache.org>.
On 8/23/06, Paul Benedict <pb...@apache.org> wrote:
>
> Ted Husted wrote:
> > Use "action-id" then. The point is that moniker "alias" is going to
> > cause confusion, since it already means something entirely different
> > within the Struts 2 community.
> Right now attributes are squarely mapped to properties. Java does not
> allow dashes in a property name, so what is a workaround?
Why not just call it actionId instead of action-id? Done.
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pb...@apache.org>.
Ted Husted wrote:
> Use "action-id" then. The point is that moniker "alias" is going to
> cause confusion, since it already means something entirely different
> within the Struts 2 community.
Right now attributes are squarely mapped to properties. Java does not
allow dashes in a property name, so what is a workaround?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Ted Husted <hu...@apache.org>.
Use "action-id" then. The point is that moniker "alias" is going to
cause confusion, since it already means something entirely different
within the Struts 2 community. Struts 2 does *not* have a logical name
for Actions. The "name" attribute is the exact equivalent of the
"path" attribute in Struts 1. If this idiom proves useful for Struts
1, we may want to bring it forward to Struts 2, and so it's important
to use terminology that won't confuse the Struts 2 community.
-Ted.
On 8/23/06, Paul Benedict <pb...@apache.org> wrote:
> >> Use the moniker "action-ref" instead of "alias"
>
> On the action mapping? <action action-ref>? or are you talking about the
> forward? If it is no the action, I do not think that jives with the
> current usage of -ref in the field. In Spring, it references something
> already defined; it does not define something.
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pb...@apache.org>.
>> Use the moniker "action-ref" instead of "alias"
On the action mapping? <action action-ref>? or are you talking about the
forward? If it is no the action, I do not think that jives with the
current usage of -ref in the field. In Spring, it references something
already defined; it does not define something.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Ted Husted <hu...@apache.org>.
On 8/23/06, Paul Benedict <pa...@gmail.com> wrote:
> I am not sure I understand the whole of your email.
* Use the moniker "action-ref" instead of "alias"
* If you haven't already, if an action-ref is not specified, use the
path for the default action-ref
One way to do the latter is in the JavaBean. If action-ref is null,
return the path instead.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Paul Benedict <pa...@gmail.com>.
Ted,
I am not sure the name is going to matter at all in 1.x because the
naming conventions are so different. What is "name" on an S2 action
mapping is awkwardly the bean name in S1. So while shooting for the same
conceptual names is a good thing, S1 already blew it :-)
I am not sure I understand the whole of your email. So let me emphasize
one point and then perhaps you can tell me if it is what you're saying:
I am trying to provide transparency. Whether the destination of a
forward is a URI (starts with a slash) or a logical name, any code
written in Struts 1.x will NOT have to change. That was my goal and I
think I achieved it because all I did was alter the action mappings and
JSP, and it ran like it did before.
Paul
Ted Husted wrote:
> In Struts 2, the action mapping names attributes still hash to URIs,
> so we still have the same problem. Though, I can understand why
> someone would want to give action mappings logical names that are not
> part of the "business logic".
>
> Right now, the term "alias" is used in Struts 2 to indicate a
> "dispatch" method -- an alternative "execute" method. Using the same
> term to mean something else in the Struts 1 vernacular might be
> confusing.
>
> Following Struts 2 conventions, we might want to call the logical name
> "action-ref". I'd suggest that the action-ref default to the path,
> unless specified in the mapping, so that every action mapping is
> guaranteed to have an action-ref.
>
> I'm thinking of proposing class aliases for XWork 2, where we could
> give an internal logical name to FQNs. Then in the class (or type)
> element, we could refer to the alias rather than the full package and
> class name. Since the term "alias" was taken, my thought was to call
> these element "class-ref".
>
> If we apply the patch, we could add the set-properties capability to
> Struts 1.3, and then schedule a DTD change for Struts 1.4.
> Historically, we have not made DTD changes as part of a milestone
> (#.#.x) release.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.x: Action Aliasing
Posted by Ted Husted <hu...@apache.org>.
In Struts 2, the action mapping names attributes still hash to URIs,
so we still have the same problem. Though, I can understand why
someone would want to give action mappings logical names that are not
part of the "business logic".
Right now, the term "alias" is used in Struts 2 to indicate a
"dispatch" method -- an alternative "execute" method. Using the same
term to mean something else in the Struts 1 vernacular might be
confusing.
Following Struts 2 conventions, we might want to call the logical name
"action-ref". I'd suggest that the action-ref default to the path,
unless specified in the mapping, so that every action mapping is
guaranteed to have an action-ref.
I'm thinking of proposing class aliases for XWork 2, where we could
give an internal logical name to FQNs. Then in the class (or type)
element, we could refer to the alias rather than the full package and
class name. Since the term "alias" was taken, my thought was to call
these element "class-ref".
If we apply the patch, we could add the set-properties capability to
Struts 1.3, and then schedule a DTD change for Struts 1.4.
Historically, we have not made DTD changes as part of a milestone
(#.#.x) release.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org