Re: Wildcard action paths
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:
> >
> > >type="...PathInfoForwardAction"
> >parameter=".tile.name">
> >
> >
> > ...
> >
> >
> > 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:
> >>>
> >>> >>> type="...PathInfoForwardAction"
> >>> parameter=".tile.name">
> >>>
> >>>
> >>> ...
> >>>
> >>>
> >>>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:
> >>
> >> >> type="...PathInfoForwardAction"
> >> parameter=".tile.name">
> >>
> >> ...
> >>
> >>
> >>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:
>
> 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
> >>>wildcar
Re: Wildcard action paths
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:
...
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:
...
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:
...
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:
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
Re: Wildcard action paths
Ok, but even if that is what she was wanting, it could still use the
same struts config syntax I pointed out:
...
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:
> >
> > >type="...PathInfoForwardAction"
> >parameter=".tile.name">
> >
> >
> > ...
> >
> >
> > 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:
>
> type="...PathInfoForwardAction"
>parameter=".tile.name">
>
> ...
>
>
> 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:
> > >
> > > > > 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 th
Re: Wildcard action paths
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:
>
> type="...PathInfoForwardAction"
>parameter=".tile.name">
>
>
> ...
>
>
> 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:
...
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:
> >
> > > 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]
Re: Wildcard action paths
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:
...
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:
>
> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
I ended up writing an action which let me do this: 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]
Re: Wildcard action paths
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]
Re: Wildcard action paths
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]
Re: Wildcard action paths
Michael Jouravlev wrote: On 6/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote: I didn't get any response to this last time so I'm asking again... :-) I'd like to replace URLs like this: /Sections/Subsections/?section=Section1&subsection=SubSection1 with URLs like this: /Sections/Section1/Subsections/Subsection1 You don't want to solve this with mod_rewrite, do you? No, I don't want to require Apache. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
On 6/14/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > The problem with that approach is duplication of information: you have > to know the URL structure in the action / tag / whatever that does the > URL parsing, as well as in struts-config.xml. And I don't need a single > pattern, there would be a number of them, so the URL parsing would > quickly get messy. > > L. You are starting to lose me here. To quote your original example: with URLs like this: /Sections/Section1/Subsections/Subsection1 An action mapping like this will match that URL: The problem is, there's then no way to get what the wildcards matched in the view (JSP). For reasons discussed elsewhere I don't want to put a different action in front of each view, so I need a more general solution. 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? 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. -Van -- - Mike "Van" Riper [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
On 6/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > I didn't get any response to this last time so I'm asking again... :-) > > I'd like to replace URLs like this: > >/Sections/Subsections/?section=Section1&subsection=SubSection1 > > with URLs like this: > >/Sections/Section1/Subsections/Subsection1 You don't want to solve this with mod_rewrite, do you? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
Van wrote: The problem is, there's then no way to get what the wildcards matched in the view (JSP). For reasons discussed elsewhere I don't want to put a different action in front of each view, so I need a more general solution. This seems so obvious to me that I'm probably missing something about your requirements. Why can't you access the HttpServleRequest.getRequestURI() method and then process the returned URI string in your subclass of the Struts ForwardAction? The execute method for an Action class gets the incoming request object as one of the parameters. Your subclass can process the URI for the section and subsection values and set them as request attributes. For that matter, the request object is available to your JSP pages as well: http://tinyurl.com/9jn4d Of course, you would have to write scriptlet logic or define a JSP custom tag to encapsulate the logic to parse for the section/subsection values in order to handle it directly in the JSPs. All easily doable though. I'm just not seeing what the problem is here. The problem with that approach is duplication of information: you have to know the URL structure in the action / tag / whatever that does the URL parsing, as well as in struts-config.xml. And I don't need a single pattern, there would be a number of them, so the URL parsing would quickly get messy. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
On 6/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > I'd like to replace URLs like this: > > /Sections/Subsections/?section=Section1&subsection=SubSection1 > > with URLs like this: > > /Sections/Section1/Subsections/Subsection1 > > An action mapping like this will match that URL: > > type="org.apache.struts.actions.ForwardAction" > parameter=".tiles.mytile"/> > > The problem is, there's then no way to get what the wildcards matched in > the view (JSP). For reasons discussed elsewhere I don't want to put a > different action in front of each view, so I need a more general solution. This seems so obvious to me that I'm probably missing something about your requirements. Why can't you access the HttpServleRequest.getRequestURI() method and then process the returned URI string in your subclass of the Struts ForwardAction? The execute method for an Action class gets the incoming request object as one of the parameters. Your subclass can process the URI for the section and subsection values and set them as request attributes. For that matter, the request object is available to your JSP pages as well: http://tinyurl.com/9jn4d Of course, you would have to write scriptlet logic or define a JSP custom tag to encapsulate the logic to parse for the section/subsection values in order to handle it directly in the JSPs. All easily doable though. I'm just not seeing what the problem is here. -Van -- - Mike "Van" Riper [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard action paths
Sorry about the typo, I was referring to HttpServletRequest below. -Van On 6/13/05, Van <[EMAIL PROTECTED]> wrote: > On 6/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > I'd like to replace URLs like this: > > > > /Sections/Subsections/?section=Section1&subsection=SubSection1 > > > > with URLs like this: > > > > /Sections/Section1/Subsections/Subsection1 > > > > An action mapping like this will match that URL: > > > >> type="org.apache.struts.actions.ForwardAction" > > parameter=".tiles.mytile"/> > > > > The problem is, there's then no way to get what the wildcards matched in > > the view (JSP). For reasons discussed elsewhere I don't want to put a > > different action in front of each view, so I need a more general solution. > > This seems so obvious to me that I'm probably missing something about > your requirements. Why can't you access the > HttpServleRequest.getRequestURI() method and then process the returned > URI string in your subclass of the Struts ForwardAction? The execute > method for an Action class gets the incoming request object as one of > the parameters. Your subclass can process the URI for the section and > subsection values and set them as request attributes. For that matter, > the request object is available to your JSP pages as well: > > http://tinyurl.com/9jn4d > > Of course, you would have to write scriptlet logic or define a JSP > custom tag to encapsulate the logic to parse for the > section/subsection values in order to handle it directly in the JSPs. > All easily doable though. I'm just not seeing what the problem is > here. > > -Van > > -- > - Mike "Van" Riper > [EMAIL PROTECTED] > -- - Mike "Van" Riper [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wildcard action paths
I didn't get any response to this last time so I'm asking again... :-)
I'd like to replace URLs like this:
/Sections/Subsections/?section=Section1&subsection=SubSection1
with URLs like this:
/Sections/Section1/Subsections/Subsection1
An action mapping like this will match that URL:
The problem is, there's then no way to get what the wildcards matched in
the view (JSP). For reasons discussed elsewhere I don't want to put a
different action in front of each view, so I need a more general solution.
I'd like to sub-class ForwardAction and put the wildcard matches from
the URL into a map which can then go into request context. But how can I
pass the matches *into* the action? I can't user the 'parameter'
attribute since it's already used to specify where to forward to.
I thought about this:
But the wildcard URL matching stops working if I do that and anyway I
don't think dereferencing the matches would work in that context.
So, any other suggestions? The only thing I can think of right now is
overloading 'parameter', something like
parameter=".tiles.mytile;section={1},subsection={2}"
and doing the necessary fixup in my action class. Can anyone suggest
anything better?
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
