I think you've got it.
As far as I can tell, there is no other way to support bookmarking of a
restful request. You must do a redirect and it must be able to pass
params.
If everyone agrees that adding redirect params to the faces-config is a
good solution, we are back to the question of what to do with
experimental features like this.
The way I implemented it, it doesn't actually change the existing xsd.
I just created a new one and added that to the list of things the
digester understands. So you can still use the unchanged
web-facesconfig_1_2.xsd, but for redirect params you would use
web-facesconfig_research.xsd. In effect, I extended the xsd through
versioning instead of using the extension tags.
I'm actually pretty new to xsd, so I'm not sure if it makes sense to use
the extension tags for this or not. It looks like I would have to use
the navigation-rule-extension. Then I would have to re-implement all
the stuff for navigation-case, from-outcome, to-view-id, etc. Right?
Is there an easy way to just say, "Add an element to the redirect tag"?
In the java code, all I had to do was make a small change to the
NavigationHandlerImpl. To get this to work, I had to check the
CaseStruct for any redirect params. There is no
implementation-independent way to read the
CaseStruct/ApplicationAssociate. I have attached the new
NavigationHandlerImpl for reference. Look at the call to
addRedirectParams().
In short, I don't see a reasonable way to plug in a new
NavigationHandler for this without reimplementing a lot of stuff.
Therefore, this might not be a candidate for the jsf-extensions project.
Comments?
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:29 AM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: Redirect Params
>
> I guess the problem is that with restful communication, unless the
> from-outcome is part of the incoming request, there's no good way of
> routing the navigation case in this example. But I could still be
> missing the keystone in the proposal.
>
> I think people are already doing parameter assignment via
> managed-properties, the redirect association on a restful request
would
> then be a target method expression.
>
> Stan Silvert wrote:
> > 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
> >>
> >
> >
---------------------------------------------------------------------
> > 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