Here is what I've got. I'm not sure if this makes it any clearer.
<navigation-rule>
<navigation-case>
<from-outcome>result</from-outcome>
<to-view-id>/result.jsp</to-view-id>
<redirect>
<redirect-param>
<redirect-param-name>foo</redirect-param-name>
<redirect-param-value>#{random.int}</redirect-param-value>
</redirect-param>
<redirect-param>
<redirect-param-name>foo2</redirect-param-name>
<redirect-param-value>simplevalue</redirect-param-value>
</redirect-param>
</redirect>
</navigation-case>
<navigation-case>
<from-outcome>goback</from-outcome>
<to-view-id>/welcomeJSF.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
The real use case would be a bookmarkable search result screen. You
need to do a redirect to be able to bookmark your result. You need to
specify params in the URL to get back to the same results screen at a
later time.
Something like:
addresssearch.faces?lastname=Smith&firstname=John
Stan Silvert
JBoss, a division of RedHat
ssilvert_at_jboss.com
> -----Original Message-----
> From: Jacob Hookom [mailto:jacob_at_hookom.net]
> Sent: Tuesday, June 13, 2006 10:08 AM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: Redirect Params
>
> nm-- can you give a larger segment of your redirect xml within the
> navigation case?
>
> Jacob Hookom wrote:
> > Your original use case used the EL stack to produce:
> >
> > myredirectedpage.faces?foo=12345
> >
> > So couldn't we just evaluate the intended view-id as an el
expression
> > to get the same result without schema modifications under 1.2?
> >
> > Stan Silvert wrote:
> >> I'm lost. How does that solve the bookmarking problem?
> >>
> >> Stan Silvert
> >> JBoss, a division of RedHat
> >> ssilvert_at_jboss.com
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jacob Hookom [mailto:jacob_at_hookom.net]
> >>> Sent: Tuesday, June 13, 2006 9:44 AM
> >>> To: dev_at_javaserverfaces.dev.java.net
> >>> Subject: Re: Redirect Params
> >>>
> >>> The only reason I would see for breaking out the params like that
is
> >>>
> >> for
> >>
> >>> converter attachment-- but frameworks such as Struts and WebWork
> >>>
> >> simply
> >>
> >>> evaluate the targeted view-id as an Expression, allowing:
> >>>
> >>> /foo.jsf?id=#{action.orderId}
> >>>
> >>> No schema change, just a different NavigationHandler
> >>>
> >>>
> >>>
> >>> Ed Burns wrote:
> >>>
> >>>>>>>>> On Mon, 12 Jun 2006 18:42:16 -0700, Ryan Lubke
> >>>>>>>>>
> >> <Ryan.Lubke_at_Sun.COM>
> >>
> >>> said:
> >>>
> >>>> RL> I don't believe Stan said it wasn't a good place.
> >>>>
> >>>> I'm sorry I implied that was said. I see that it was not.
> >>>>
> >>>> RL> Since jsf-extensions is a drop-in addition to be used with
JSF
> >>>> RL> implementations, I think introducing
> >>>> RL> items that break compatibility (such as XSD changes)
shouldn't
> >>>>
> >> be
> >>
> >>> there.
> >>>
> >>>> True, but what about Adam's suggestion to put it in an extension
> >>>> element?
> >>>>
> >>>> Ed
> >>>>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> --------------------------
> >>> Sent from my FrankenBerry Wireless Handheld
> >>>
> >>>
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
dev-unsubscribe_at_javaserverfaces.dev.java.net
> >>> For additional commands, e-mail:
dev-help_at_javaserverfaces.dev.java.net
> >>>
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail:
dev-help_at_javaserverfaces.dev.java.net
> >>
> >>
> >>
> >
> >
>
>
> --
> --------------------------
> Sent from my FrankenBerry Wireless Handheld
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net