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]
