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]
