You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/01/16 17:02:16 UTC
Push "find 'unknown' ActionConfig" into
ModuleConfigImpl.findActionConfig?
I'm still a little gun-shy about changing core struts classes. I
think the below is the right thing to do, but I thought I'd see first.
ModuleConfigImpl.findActionConfig(String path) currently looks for an
exact match of the path, and then uses the wild-card matching.
However, it does not honor the "unknown" setting of action configs.
That "fallback" is implemented in the RequestProcessor.
I'd propose moving that from the RequestProcessor into the
ModuleConfigImpl. This would then also involve removing a similar
fallback that I committed to the struts-chain AbstractSelectAction
class yesterday.
Does anyone object? I mentioned this in my posting about
struts-chain, but didn't get any responses on this piece.
Similarly, I believe that the "findException(Class clazz)" method in
ActionMapping should be pushed up into ActionConfig so that its
fallback strategy of looking for superclass exception handlers is
available. Is there any controversy to doing this?
How annoyed would people be if I had just made these changes and
committed them rather than asking for opinions?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Push "find 'unknown' ActionConfig" into
ModuleConfigImpl.findActionConfig?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:10 AM -0600 1/16/04, Joe Germuska wrote:
>At 8:36 AM -0800 1/16/04, David Graham wrote:
>> > I'd propose moving that from the RequestProcessor into the
>>> ModuleConfigImpl. This would then also involve removing a similar
>>> fallback that I committed to the struts-chain AbstractSelectAction
>>> class yesterday.
>>
>>How would removing it from RequestProcessor affect backwards
>>compatibility? Could subclasses be relying on the fallback being there?
>
>The fallback is inside processMapping(). processMapping already
>calls moduleConfig.findActionConfig() so the behavior would be
>identical.
Whoops. I take that back. If anyone is using a different
implementation of ModuleConfig, they may be relying on that behavior.
I forgot since ModuleConfig is one of the few interfaces at that
layer of struts.
ModuleConfig doesn't mention any fallback strategy in the doc for
findActionConfig():
"Return the action configuration for the specified path, if any;
otherwise return null."
It's arguable that the wildcard mapping in ModuleConfigImpl honors
this, but that returning the unknown action would not. Strictly
speaking, perhaps this change isn't appropriate, and the code to walk
through the configs looking for an "unknown" is easy enough to
write... I just don't like duplicating it.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Push "find 'unknown' ActionConfig" into
ModuleConfigImpl.findActionConfig?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:36 AM -0800 1/16/04, David Graham wrote:
> > I'd propose moving that from the RequestProcessor into the
>> ModuleConfigImpl. This would then also involve removing a similar
>> fallback that I committed to the struts-chain AbstractSelectAction
>> class yesterday.
>
>How would removing it from RequestProcessor affect backwards
>compatibility? Could subclasses be relying on the fallback being there?
The fallback is inside processMapping(). processMapping already
calls moduleConfig.findActionConfig() so the behavior would be
identical.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Push "find 'unknown' ActionConfig" into ModuleConfigImpl.findActionConfig?
Posted by David Graham <gr...@yahoo.com>.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> I'm still a little gun-shy about changing core struts classes. I
> think the below is the right thing to do, but I thought I'd see first.
>
> ModuleConfigImpl.findActionConfig(String path) currently looks for an
> exact match of the path, and then uses the wild-card matching.
> However, it does not honor the "unknown" setting of action configs.
> That "fallback" is implemented in the RequestProcessor.
>
> I'd propose moving that from the RequestProcessor into the
> ModuleConfigImpl. This would then also involve removing a similar
> fallback that I committed to the struts-chain AbstractSelectAction
> class yesterday.
How would removing it from RequestProcessor affect backwards
compatibility? Could subclasses be relying on the fallback being there?
>
> Does anyone object? I mentioned this in my posting about
> struts-chain, but didn't get any responses on this piece.
>
> Similarly, I believe that the "findException(Class clazz)" method in
> ActionMapping should be pushed up into ActionConfig so that its
> fallback strategy of looking for superclass exception handlers is
> available. Is there any controversy to doing this?
>
> How annoyed would people be if I had just made these changes and
> committed them rather than asking for opinions?
It's nice to discuss major changes first but most of the time you can just
commit a change and wait for someone to speak up if they disagree.
David
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Imagine if every Thursday your shoes exploded if you tied them
> the usual way. This happens to us all the time with computers, and
> nobody thinks of complaining."
> -- Jef Raskin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org