struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38343] - [extras] ParameterListActionDispatcher
Date Wed, 08 Mar 2006 05:07:05 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38343>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38343





------- Additional Comments From niallp@apache.org  2006-03-08 05:07 -------
(In reply to comment #27)
> 1) EventDispatchAction duplicates much (all?) of the dispatching code of
> EventActionDispatcher. I understand XYZDispatchAction classes are convienent,
> and while I prefer them to be phased out, other people may find them easy to
> have pre-built functionality out of the box. That's fine. My only
> recommendation here is that EventDispatchAction should use
> EventActionDispatcher internally. I think that would be a more organized
> approach to code maintenance and still provide the convienence Action
> classes you seek.

There is a slight difference between implementations that extend DispatchAction 
and those that use an ActionDispatcher. In the case of DispatchAction 
implementations the "unspecified" method is a protected method and isn't 
publically exposed. For Action implementations that use ActionDispatcher, 
unless the Action is in the same package as the ActionDispatcher, then 
the "unspecified" needs to be public. The same is also true for the "cancelled" 
method. For this reason my preference is to not use EventActionDispatcher in 
the EventDispatchAction - it keeps EventDispatchAction consistent with other 
DispatchAction flavours.

> 2) The JavaDoc reads in regards to not finding a match: "null is returned 
which
> means the unspecified method will be invoked." I believe you have changed the
> functionality so null is no longer returned, which means "unspecified" is no
> longer invoked. Can you confirm this?
>         if (defaultMethodName == null || defaultMethodName.length() == 0) {
>             String message =
>                 messages.getMessage("event.parameter", mapping.getPath());
>             LOG.error(message + " " + parameter);
>             throw new ServletException(message);
>         }
> I think above ^^^ is the issue. Didn't you already modify the base class to
> prevent the exception message from exposing the method? Was that the rationale
> behind this addition?

Yes you have a point here. Its late so I'll look at this tommorrow. The base 
class was modified to not expose input parameters, but it does display the 
mapping's parameter. In the case of this flavour though, it seemed wrong to 
expose the mapping's parameter (and therefore method names), when theres a 
facility to "obfuscate" the method names. I think I was trying to save having 
to override the unspecified method - but it looks like I've made a mistake :-(

> (3) I am okay with you removing the "impliedSingleDefault" feature. I still
> want that for my code base, so I will privately override
> EventActionDispatcher.

OK good. Thanks for the feedback.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message