You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Laurie Harper <la...@holoweb.net> on 2005/11/27 07:31:32 UTC
[shale?] mimicking wildcard action mapping paths
I suspect that Shale doesn't provide anything over-and-above the
standard JSF navigation management in this area, in which case this may
be more of a general JSF question:
I use wildcard action mapping paths extensively, which of course
continues to work unchanged with struts-faces, but I'm wondering how I'd
achieve the same goals with Shale.
Here's what I have using Struts:
- I have action mappings like
<action path="/Projects/*/Releases/*" ...
parameter="project={1};release={2}">
- My actions parse the expanded 'parameter' value into a map:
{'project' -> 'foo', 'release' -> 'bar'}
which is used to determine the data to load for the view
- My 'forward' declarations use the matches (e.g. {1}) to
specify the view to forward to,
<forward name="edit" path="/Projects/{1}/Releases/{2}/Edit/>
- The result is that I can use a URL like
.../Projects/foo/Releases/bar
instead of
...?project=foo&release=bar
and can declaratively specify the 'outcome' view w/out having
my actions mess with request parameters on the mapping forward
they return.
By having the actions parse the parameter value, I'm able to avoid
duplicating the URL path parsing semantics in two places; there's
exactly one place I specify a path matching expression, and exactly one
place where I specify how the results of that match are processed.
Using Shale (or JSF in general), I'm not sure how to achieve the same
thing. Ideally, I'd be able to do something like this:
<navigation-rule>
<from-view-id>/Projects/*/Releases/*</from-view-id>
<navigation-case>
<from-outcome>edit</from-outcome>
<to-view-id>/Projects/ReleaseEdit.jsp?project={1}&release={2}</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
or better yet, have the to-view-id refernce a logical path the way the
Struts 'forward' does -- that's the bit where I thought maybe Shale
might be able to help.
I'm still not sure how I get a backing bean setup with data supplied as
request parameters, but I think I should be able to figure that out
easily enough. The bit I have no idea how to solve is the use of path-
extra-info--based URLs...
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale?] mimicking wildcard action mapping paths
Posted by Laurie Harper <la...@holoweb.net>.
That sounds like it might provide a much less hackish solution; I'll
look into that.
Thanks,
L.
Sean Schofield wrote:
> Yould can probably implement your own NavigationHandler. Check out
> the DialogNavigationHandler in Shale. It implements custom navigation
> handling on top of the JSF standard. You could try something similar.
>
> sean
>
> On 11/28/05, Laurie Harper <la...@holoweb.net> wrote:
>> Craig McClanahan wrote:
>>> On 11/26/05, Laurie Harper <la...@holoweb.net> wrote:
>>>> I suspect that Shale doesn't provide anything over-and-above the
>>>> standard JSF navigation management in this area, in which case this may
>>>> be more of a general JSF question:
>>> Well, it does offer above-and-beyond navigation support inside a dialog, but
>>> that doesn't really address your question.
>>>
>>> I use wildcard action mapping paths extensively, which of course
>>>> continues to work unchanged with struts-faces, but I'm wondering how I'd
>>>> achieve the same goals with Shale.
>>>>
>>>> Here's what I have using Struts:
>>>>
>>>> - I have action mappings like
>>>>
>>>> <action path="/Projects/*/Releases/*" ...
>>>> parameter="project={1};release={2}">
>>>>
>>>> - My actions parse the expanded 'parameter' value into a map:
>>>>
>>>> {'project' -> 'foo', 'release' -> 'bar'}
>>>>
>>>> which is used to determine the data to load for the view
>>>>
>>>> - My 'forward' declarations use the matches (e.g. {1}) to
>>>> specify the view to forward to,
>>>>
>>>> <forward name="edit" path="/Projects/{1}/Releases/{2}/Edit/>
>>>>
>>>> - The result is that I can use a URL like
>>>>
>>>> .../Projects/foo/Releases/bar
>>>>
>>>> instead of
>>>>
>>>> ...?project=foo&release=bar
>>>>
>>>> and can declaratively specify the 'outcome' view w/out having
>>>> my actions mess with request parameters on the mapping forward
>>>> they return.
>>>>
>>>> By having the actions parse the parameter value, I'm able to avoid
>>>> duplicating the URL path parsing semantics in two places; there's
>>>> exactly one place I specify a path matching expression, and exactly one
>>>> place where I specify how the results of that match are processed.
>>>>
>>>> Using Shale (or JSF in general), I'm not sure how to achieve the same
>>>> thing. Ideally, I'd be able to do something like this:
>>>>
>>>> <navigation-rule>
>>>> <from-view-id>/Projects/*/Releases/*</from-view-id>
>>>> <navigation-case>
>>>> <from-outcome>edit</from-outcome>
>>>>
>>>>
>>>> <to-view-id>/Projects/ReleaseEdit.jsp?project={1}&release={2}</to-view-id>
>>>> <redirect/>
>>>> </navigation-case>
>>>> </navigation-rule>
>>>>
>>>>
>>>> or better yet, have the to-view-id refernce a logical path the way the
>>>> Struts 'forward' does -- that's the bit where I thought maybe Shale
>>>> might be able to help.
>>>
>>> You can indeed use wildcards in from-view-id (or from-outcome) clauses in
>>> the navigation rules ... but that doesn't deal with the parameter
>>> substitution you are proposing.
>> Good to know that wildcards can be used like that. I guess that would
>> get me part way there...
>>
>>> I'm still not sure how I get a backing bean setup with data supplied as
>>>> request parameters, but I think I should be able to figure that out
>>>> easily enough. The bit I have no idea how to solve is the use of path-
>>>> extra-info--based URLs...
>>>
>>> JSF prefers that you forget such things as URLs and request parameters
>>> actually exist :-). What you are passing around is typically model data, so
>>> the preferred solution is to use request or session scope attributes
>>> (depending on whether you're doing a redirect), or properties of such a
>>> request or session scope bean.
>> That's all very well, but doesn't fit my requirements very well ;-)
>> Specifically, that resources be directly addressable by URL and
>> bookmarkable.
>>
>> Using wildcards in the from-view-id as above, and implementing the URL
>> path processing in a filter that effectively added the extracted data as
>> additional request parameters, I should then be able to do something
>> like this, right?
>>
>> <navigation-rule>
>> <from-view-id>/Projects/*/Releases/*</from-view-id>
>> <navigation-case>
>> <from-outcome>edit</from-outcome>
>> <to-view-id>
>> /Projects/ReleaseEdit.jsp?
>> project=#{param[project]&
>> release=#{param[release]}
>> </to-view-id>
>> <redirect/>
>> </navigation-case>
>> </navigation-rule>
>>
>> I'd lose having the URL patterns localized to a single place, though.
>>
>> L.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale?] mimicking wildcard action mapping paths
Posted by Sean Schofield <se...@gmail.com>.
Yould can probably implement your own NavigationHandler. Check out
the DialogNavigationHandler in Shale. It implements custom navigation
handling on top of the JSF standard. You could try something similar.
sean
On 11/28/05, Laurie Harper <la...@holoweb.net> wrote:
> Craig McClanahan wrote:
> > On 11/26/05, Laurie Harper <la...@holoweb.net> wrote:
> >> I suspect that Shale doesn't provide anything over-and-above the
> >> standard JSF navigation management in this area, in which case this may
> >> be more of a general JSF question:
> >
> > Well, it does offer above-and-beyond navigation support inside a dialog, but
> > that doesn't really address your question.
> >
> > I use wildcard action mapping paths extensively, which of course
> >> continues to work unchanged with struts-faces, but I'm wondering how I'd
> >> achieve the same goals with Shale.
> >>
> >> Here's what I have using Struts:
> >>
> >> - I have action mappings like
> >>
> >> <action path="/Projects/*/Releases/*" ...
> >> parameter="project={1};release={2}">
> >>
> >> - My actions parse the expanded 'parameter' value into a map:
> >>
> >> {'project' -> 'foo', 'release' -> 'bar'}
> >>
> >> which is used to determine the data to load for the view
> >>
> >> - My 'forward' declarations use the matches (e.g. {1}) to
> >> specify the view to forward to,
> >>
> >> <forward name="edit" path="/Projects/{1}/Releases/{2}/Edit/>
> >>
> >> - The result is that I can use a URL like
> >>
> >> .../Projects/foo/Releases/bar
> >>
> >> instead of
> >>
> >> ...?project=foo&release=bar
> >>
> >> and can declaratively specify the 'outcome' view w/out having
> >> my actions mess with request parameters on the mapping forward
> >> they return.
> >>
> >> By having the actions parse the parameter value, I'm able to avoid
> >> duplicating the URL path parsing semantics in two places; there's
> >> exactly one place I specify a path matching expression, and exactly one
> >> place where I specify how the results of that match are processed.
> >>
> >> Using Shale (or JSF in general), I'm not sure how to achieve the same
> >> thing. Ideally, I'd be able to do something like this:
> >>
> >> <navigation-rule>
> >> <from-view-id>/Projects/*/Releases/*</from-view-id>
> >> <navigation-case>
> >> <from-outcome>edit</from-outcome>
> >>
> >>
> >> <to-view-id>/Projects/ReleaseEdit.jsp?project={1}&release={2}</to-view-id>
> >> <redirect/>
> >> </navigation-case>
> >> </navigation-rule>
> >>
> >>
> >> or better yet, have the to-view-id refernce a logical path the way the
> >> Struts 'forward' does -- that's the bit where I thought maybe Shale
> >> might be able to help.
> >
> >
> > You can indeed use wildcards in from-view-id (or from-outcome) clauses in
> > the navigation rules ... but that doesn't deal with the parameter
> > substitution you are proposing.
>
> Good to know that wildcards can be used like that. I guess that would
> get me part way there...
>
> > I'm still not sure how I get a backing bean setup with data supplied as
> >> request parameters, but I think I should be able to figure that out
> >> easily enough. The bit I have no idea how to solve is the use of path-
> >> extra-info--based URLs...
> >
> >
> > JSF prefers that you forget such things as URLs and request parameters
> > actually exist :-). What you are passing around is typically model data, so
> > the preferred solution is to use request or session scope attributes
> > (depending on whether you're doing a redirect), or properties of such a
> > request or session scope bean.
>
> That's all very well, but doesn't fit my requirements very well ;-)
> Specifically, that resources be directly addressable by URL and
> bookmarkable.
>
> Using wildcards in the from-view-id as above, and implementing the URL
> path processing in a filter that effectively added the extracted data as
> additional request parameters, I should then be able to do something
> like this, right?
>
> <navigation-rule>
> <from-view-id>/Projects/*/Releases/*</from-view-id>
> <navigation-case>
> <from-outcome>edit</from-outcome>
> <to-view-id>
> /Projects/ReleaseEdit.jsp?
> project=#{param[project]&
> release=#{param[release]}
> </to-view-id>
> <redirect/>
> </navigation-case>
> </navigation-rule>
>
> I'd lose having the URL patterns localized to a single place, though.
>
> L.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale?] mimicking wildcard action mapping paths
Posted by Laurie Harper <la...@holoweb.net>.
Craig McClanahan wrote:
> On 11/26/05, Laurie Harper <la...@holoweb.net> wrote:
>> I suspect that Shale doesn't provide anything over-and-above the
>> standard JSF navigation management in this area, in which case this may
>> be more of a general JSF question:
>
> Well, it does offer above-and-beyond navigation support inside a dialog, but
> that doesn't really address your question.
>
> I use wildcard action mapping paths extensively, which of course
>> continues to work unchanged with struts-faces, but I'm wondering how I'd
>> achieve the same goals with Shale.
>>
>> Here's what I have using Struts:
>>
>> - I have action mappings like
>>
>> <action path="/Projects/*/Releases/*" ...
>> parameter="project={1};release={2}">
>>
>> - My actions parse the expanded 'parameter' value into a map:
>>
>> {'project' -> 'foo', 'release' -> 'bar'}
>>
>> which is used to determine the data to load for the view
>>
>> - My 'forward' declarations use the matches (e.g. {1}) to
>> specify the view to forward to,
>>
>> <forward name="edit" path="/Projects/{1}/Releases/{2}/Edit/>
>>
>> - The result is that I can use a URL like
>>
>> .../Projects/foo/Releases/bar
>>
>> instead of
>>
>> ...?project=foo&release=bar
>>
>> and can declaratively specify the 'outcome' view w/out having
>> my actions mess with request parameters on the mapping forward
>> they return.
>>
>> By having the actions parse the parameter value, I'm able to avoid
>> duplicating the URL path parsing semantics in two places; there's
>> exactly one place I specify a path matching expression, and exactly one
>> place where I specify how the results of that match are processed.
>>
>> Using Shale (or JSF in general), I'm not sure how to achieve the same
>> thing. Ideally, I'd be able to do something like this:
>>
>> <navigation-rule>
>> <from-view-id>/Projects/*/Releases/*</from-view-id>
>> <navigation-case>
>> <from-outcome>edit</from-outcome>
>>
>>
>> <to-view-id>/Projects/ReleaseEdit.jsp?project={1}&release={2}</to-view-id>
>> <redirect/>
>> </navigation-case>
>> </navigation-rule>
>>
>>
>> or better yet, have the to-view-id refernce a logical path the way the
>> Struts 'forward' does -- that's the bit where I thought maybe Shale
>> might be able to help.
>
>
> You can indeed use wildcards in from-view-id (or from-outcome) clauses in
> the navigation rules ... but that doesn't deal with the parameter
> substitution you are proposing.
Good to know that wildcards can be used like that. I guess that would
get me part way there...
> I'm still not sure how I get a backing bean setup with data supplied as
>> request parameters, but I think I should be able to figure that out
>> easily enough. The bit I have no idea how to solve is the use of path-
>> extra-info--based URLs...
>
>
> JSF prefers that you forget such things as URLs and request parameters
> actually exist :-). What you are passing around is typically model data, so
> the preferred solution is to use request or session scope attributes
> (depending on whether you're doing a redirect), or properties of such a
> request or session scope bean.
That's all very well, but doesn't fit my requirements very well ;-)
Specifically, that resources be directly addressable by URL and
bookmarkable.
Using wildcards in the from-view-id as above, and implementing the URL
path processing in a filter that effectively added the extracted data as
additional request parameters, I should then be able to do something
like this, right?
<navigation-rule>
<from-view-id>/Projects/*/Releases/*</from-view-id>
<navigation-case>
<from-outcome>edit</from-outcome>
<to-view-id>
/Projects/ReleaseEdit.jsp?
project=#{param[project]&
release=#{param[release]}
</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
I'd lose having the URL patterns localized to a single place, though.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale?] mimicking wildcard action mapping paths
Posted by Craig McClanahan <cr...@apache.org>.
On 11/26/05, Laurie Harper <la...@holoweb.net> wrote:
>
> I suspect that Shale doesn't provide anything over-and-above the
> standard JSF navigation management in this area, in which case this may
> be more of a general JSF question:
Well, it does offer above-and-beyond navigation support inside a dialog, but
that doesn't really address your question.
I use wildcard action mapping paths extensively, which of course
> continues to work unchanged with struts-faces, but I'm wondering how I'd
> achieve the same goals with Shale.
>
> Here's what I have using Struts:
>
> - I have action mappings like
>
> <action path="/Projects/*/Releases/*" ...
> parameter="project={1};release={2}">
>
> - My actions parse the expanded 'parameter' value into a map:
>
> {'project' -> 'foo', 'release' -> 'bar'}
>
> which is used to determine the data to load for the view
>
> - My 'forward' declarations use the matches (e.g. {1}) to
> specify the view to forward to,
>
> <forward name="edit" path="/Projects/{1}/Releases/{2}/Edit/>
>
> - The result is that I can use a URL like
>
> .../Projects/foo/Releases/bar
>
> instead of
>
> ...?project=foo&release=bar
>
> and can declaratively specify the 'outcome' view w/out having
> my actions mess with request parameters on the mapping forward
> they return.
>
> By having the actions parse the parameter value, I'm able to avoid
> duplicating the URL path parsing semantics in two places; there's
> exactly one place I specify a path matching expression, and exactly one
> place where I specify how the results of that match are processed.
>
> Using Shale (or JSF in general), I'm not sure how to achieve the same
> thing. Ideally, I'd be able to do something like this:
>
> <navigation-rule>
> <from-view-id>/Projects/*/Releases/*</from-view-id>
> <navigation-case>
> <from-outcome>edit</from-outcome>
>
>
> <to-view-id>/Projects/ReleaseEdit.jsp?project={1}&release={2}</to-view-id>
> <redirect/>
> </navigation-case>
> </navigation-rule>
>
>
> or better yet, have the to-view-id refernce a logical path the way the
> Struts 'forward' does -- that's the bit where I thought maybe Shale
> might be able to help.
You can indeed use wildcards in from-view-id (or from-outcome) clauses in
the navigation rules ... but that doesn't deal with the parameter
substitution you are proposing.
I'm still not sure how I get a backing bean setup with data supplied as
> request parameters, but I think I should be able to figure that out
> easily enough. The bit I have no idea how to solve is the use of path-
> extra-info--based URLs...
JSF prefers that you forget such things as URLs and request parameters
actually exist :-). What you are passing around is typically model data, so
the preferred solution is to use request or session scope attributes
(depending on whether you're doing a redirect), or properties of such a
request or session scope bean.
L.
Craig