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");

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}&amp;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]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to