Don, that absolutely rocks, you're the man! :-) Really, that's exactly
what I expected and wanted to do in the config file, and that code
snipet makes things even cleaner. You've just given me the means to
collapse an ugly hack into a nice, clean, properly encapsulated solution.
Thank you for that. Is this in CVS head, or posted as a patch somewhere?
L.
Don Brown wrote:
Ok, but even if that is what she was wanting, it could still use the
same struts config syntax I pointed out:
<action path="/foo/*/bar/*"
type="...PathInfoForwardAction"
parameter=".tile.name">
<set-property key="foo" value="{1}" />
<set-property key="bar" value="{2}" />
...
</action>
Then in PathInfoForwardAction:
for (Iterator i = mapping.getProperties().entrySet().iterator();
i.hasNext(); ) {
Map.Entry entry = (Map.Entry)i.next();
String key = (String)entry.getKey();
String value = (String)entry.getValue();
...
}
In this way, you still have the clean configuration, and still your
Action can take any number of parameters and do something with them.
Don
On 6/17/05, Van <[EMAIL PROTECTED]> wrote:
On 6/17/05, Don Brown <[EMAIL PROTECTED]> wrote:
Ok, what about this:
I added the ability to pass multiple request-time values to the Action
using the ActionConfig properties. This means, in your case, your
struts config would look like:
<action path="/foo/*/bar/*"
type="...PathInfoForwardAction"
parameter=".tile.name">
<set-property key="foo" value="{1}" />
<set-property key="bar" value="{2}" />
...
</action>
In your PathInfoForwardAction, you can now access those values using:
... = mapping.getProperty("foo");
... = mapping.getProperty("bar");
You may have missed that this is only one of 10 or more different
wildcard action mappings in Laurie's application. At least, that is my
understanding now. So, there are different foo/bar names for some of
them and Laurie wanted *one* action to process them all. Of course,
this approach can still work even with that more general requirement
like so:
<action path="/foo/*/bar/*"
type="...PathInfoForwardAction"
parameter=".tile.name">
<set-property key="wildcards" value="foo={1},bar={2}" />
...
</action>
In your PathInfoForwardAction, you can now extract your wildcard mapping info:
... = mapping.getProperty("wildcards");
// Then split it up into the separate wildcard mapping segments
// with no assumptions about what the foo/bar names will be.
...
-Van
--
- Mike "Van" Riper
[EMAIL PROTECTED]
Thanks for bringing this up as it has been a problem of mine that I
haven't revisited since before properties were added to ActionConfig
by Joe I believe. Hopefully this should make things more simple and
straightforward.
Don
On 6/17/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
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]
