You can get a copy in the nightly builds -
http://svn.apache.org/builds/struts/nightly/
They are of the 1.3-dev branch so if you haven't already tried a 1.3
build, you might have some other migration issues. Glad to hear it
was what you were looking for.
Don
On 6/18/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
