You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/06/22 15:19:59 UTC
redirect navigation rule and request scoped data
Hi!
As you might know, if you have a navigation rule with <redirect />
configuration you'll lose all the request scoped data like:
* managed beans
* messages
* locale
I've checked in the RedirectTrackerManager into tomahawk-sandbox which
is a try to solve this problem.
You have nothing else to do than to put the tomahawk-sandbox.jar in your
WEB-INF/lib - everything else will work automatically.
It uses some crude tricks to make it work (but still in an RI compatible
way), and so it might break your application.
If you need other parts of tomahawk-sandbox please do the following:
1) report the error at jira http://issues.apache.org/jira
2) unpack the file faces-config.xml from tomahawk-sandbox.jar and
comment these lines:
<phase-listener>org.apache.myfaces.custom.redirectTracker.RedirectTrackerPhaseListener</phase-listener>
<factory>
<faces-context-factory>org.apache.myfaces.custom.redirectTracker.RedirectTrackerFacesContextFactory</faces-context-factory>
</factory>
<application>
<variable-resolver>org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver</variable-resolver>
</application>
and repack it again.
Have fun!
Ciao,
Mario
Re: redirect navigation rule and request scoped data
Posted by Cosma Colanicchia <co...@gmail.com>.
Note that I was thinking more about request parameters than
request-scoped objects.. not really the same thing :-)
Bye
Cosma
2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> I had in mind something like this:
>
> <navigation-rule>
> <from-view-id>*</from-view-id>
> <navigation-case>
> <from-outcome>gotoEditPerson</from-outcome>
> <to-view-id>/person/edit.jspx(personId)</to-view-id>
> <navigation-case>
> </navigation-rule>
>
> See the <to-view-id>: that view declares that it "wants" a personId
> parameter. The place where this syntax should be interpreted is the
> NavigationHandler, which is also the place where redirection caused by
> <redirect/> tag is executed.. this way the NavigationHandler could
> "save" only the parameters that the destination page declare to accept
> (it could of course save other objects not declared like the locale).
>
> Maybe I'm obsessed with strong type checking, but I'd really like
> having my views declaring their interface (input parameters).. :-)
>
> Ciao
> Cosma
>
>
>
> 2006/6/23, Mario Ivankovits <ma...@ops.co.at>:
> > Hi!
> > > It would be better to have a context initialization parameter to
> > > enable this behaviour.. sometimes it is "expected" to drop request
> > > scoped stuff on redirects :).
> > Yes, when I add the "number of redirects" configuration I'll add this too.
> >
> > > BTW, nice idea..
> > Thanks!
> >
> > > Some days ago I was thinking about something similar but "selective",
> > > with an extended navigation rule syntax allowing views to declare the
> > > objects to persist.
> > Hmmmm .... what I can do is to allow to configure something like a
> > TrackRedirectInterface with a method like "int trackRedirect(....)"
> > where one can return a bit combination (or something simmilar) to tell
> > the RedirectTracker which information to save. e.g. even if you drop
> > your beans, you will keep the messages.
> >
> >
> > Thanks for your input!
> >
> > Ciao,
> > Mario
> >
> >
>
Re: redirect navigation rule and request scoped data
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> <navigation-rule>
> <from-view-id>*</from-view-id>
> <navigation-case>
> <from-outcome>gotoEditPerson</from-outcome>
> <to-view-id>/person/edit.jspx(personId)</to-view-id>
> <navigation-case>
> </navigation-rule>
Ok. By default I would like to behave the <redirect/> case the same way
like if its not added to the navigation case. But I'll keep your
suggestion in mind when defining the TrackRedirectInterface (or
whatever) interface so that a custom implementation will allow your
style too.
> Maybe I'm obsessed with strong type checking, but I'd really like
> having my views declaring their interface (input parameters).. :-)
Maybe. But I think the major use case of <redirect /> is to change the
url in the browser address bar. If you see it that way then it is not to
"define a view input interface" but it is a try to solve a "defect" in
JSF. Well, "defect" sound too harsh.
Ciao,
Mario
Re: redirect navigation rule and request scoped data
Posted by Cosma Colanicchia <co...@gmail.com>.
I had in mind something like this:
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>gotoEditPerson</from-outcome>
<to-view-id>/person/edit.jspx(personId)</to-view-id>
<navigation-case>
</navigation-rule>
See the <to-view-id>: that view declares that it "wants" a personId
parameter. The place where this syntax should be interpreted is the
NavigationHandler, which is also the place where redirection caused by
<redirect/> tag is executed.. this way the NavigationHandler could
"save" only the parameters that the destination page declare to accept
(it could of course save other objects not declared like the locale).
Maybe I'm obsessed with strong type checking, but I'd really like
having my views declaring their interface (input parameters).. :-)
Ciao
Cosma
2006/6/23, Mario Ivankovits <ma...@ops.co.at>:
> Hi!
> > It would be better to have a context initialization parameter to
> > enable this behaviour.. sometimes it is "expected" to drop request
> > scoped stuff on redirects :).
> Yes, when I add the "number of redirects" configuration I'll add this too.
>
> > BTW, nice idea..
> Thanks!
>
> > Some days ago I was thinking about something similar but "selective",
> > with an extended navigation rule syntax allowing views to declare the
> > objects to persist.
> Hmmmm .... what I can do is to allow to configure something like a
> TrackRedirectInterface with a method like "int trackRedirect(....)"
> where one can return a bit combination (or something simmilar) to tell
> the RedirectTracker which information to save. e.g. even if you drop
> your beans, you will keep the messages.
>
>
> Thanks for your input!
>
> Ciao,
> Mario
>
>
Re: redirect navigation rule and request scoped data
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> It would be better to have a context initialization parameter to
> enable this behaviour.. sometimes it is "expected" to drop request
> scoped stuff on redirects :).
Yes, when I add the "number of redirects" configuration I'll add this too.
> BTW, nice idea..
Thanks!
> Some days ago I was thinking about something similar but "selective",
> with an extended navigation rule syntax allowing views to declare the
> objects to persist.
Hmmmm .... what I can do is to allow to configure something like a
TrackRedirectInterface with a method like "int trackRedirect(....)"
where one can return a bit combination (or something simmilar) to tell
the RedirectTracker which information to save. e.g. even if you drop
your beans, you will keep the messages.
Thanks for your input!
Ciao,
Mario
Re: redirect navigation rule and request scoped data
Posted by Cosma Colanicchia <co...@gmail.com>.
It would be better to have a context initialization parameter to
enable this behaviour.. sometimes it is "expected" to drop request
scoped stuff on redirects :). BTW, nice idea..
Some days ago I was thinking about something similar but "selective",
with an extended navigation rule syntax allowing views to declare the
objects to persist.
Ciao
Cosma
2006/6/22, Mario Ivankovits <ma...@ops.co.at>:
> Hi!
>
> As you might know, if you have a navigation rule with <redirect />
> configuration you'll lose all the request scoped data like:
> * managed beans
> * messages
> * locale
>
> I've checked in the RedirectTrackerManager into tomahawk-sandbox which
> is a try to solve this problem.
>
> You have nothing else to do than to put the tomahawk-sandbox.jar in your
> WEB-INF/lib - everything else will work automatically.
> It uses some crude tricks to make it work (but still in an RI compatible
> way), and so it might break your application.
>
> If you need other parts of tomahawk-sandbox please do the following:
>
> 1) report the error at jira http://issues.apache.org/jira
> 2) unpack the file faces-config.xml from tomahawk-sandbox.jar and
> comment these lines:
>
>
> <phase-listener>org.apache.myfaces.custom.redirectTracker.RedirectTrackerPhaseListener</phase-listener>
>
> <factory>
>
> <faces-context-factory>org.apache.myfaces.custom.redirectTracker.RedirectTrackerFacesContextFactory</faces-context-factory>
> </factory>
>
> <application>
>
> <variable-resolver>org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver</variable-resolver>
> </application>
>
>
> and repack it again.
>
>
> Have fun!
>
> Ciao,
> Mario
>
>