I ended up writing an action which let me do this:
<action path="/foo/*/bar/*"
type="...PathInfoForwardAction"
parameter=".tile.name;foo={1}&bar={2}"/>
The action splits the parameter, builds a map from the name=value pairs
and sticks it in request scope then resets parameter. Except it doesn't;
ActionMapping.setParameter() throws a runtime exception, so I have to
painfully construct a duplicate with the updated 'parameter' value (or
wrap it in a proxy, which would be a lot better than the 14 lines of
mNew.setFoo(mapping.getFoo()) I have now!
Ugh. I wish this wasn't so messy :-(
L.
Don Brown wrote:
To add to your original solution: write your own subclass of
ActionConfig which overrides getParameter() to return the tiles-needed
part of the parameter attribute. Additional methods will let you
retrieve other parts. This way, your Action doesn't have to know
about parsing; it can pull clean values out of the ActionConfig
subclass.
Anyways, I know what you mean about this being difficult. The
set-property seems like a perfect solution, until you realize it is
processed by digester at deploytime, not request-time like the
parameter attribute. I think the lack of the ability to pass multiple
request-time values to the Action is a serious deficiency in Struts
right now.
Don
On 6/15/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
Van wrote:
> Okay. So maybe this isn't the only wildcard mapping you will have.
Still, you could have one SectionAction class for this particular
wildcard mapping. That would be a vast improvement over status quo.
How many different wildcard mappings do you have in this application?
Almost every page will be delivered through a wild-carded action path.
We're talking a few tens of patterns with varying amounts of similarity.
You could pass one request parameter that indicated which wildcard
pattern was involved. If you don't want to have branching logic, you
could even make this additional request parameter be a property name
and store in your application properties file the regular expression
to use against the incoming request URL to pull out the matching
wildcard values. That should scale generally to any number of
different wildcard mappings using a single Action class that was
driven by these regular expressions coming from your application
properties file.
That's still multiplying the number of places the patterns must be
stored and processed, and since Struts already does everything I want
except (apparently) a way to pass the results along that seems like a
bad idea.
Looks like my original approach (overloading 'parameter') will have to do.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
