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 <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
On 11/26/05, Laurie Harper <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
