I don't know if you guys have been trying to use implicit navigation + query params, like "?includeViewParams=true" or/and the faces-redirect option.
After read the especification, I've done a deep google search about this and I found nothing =], the problem is that the Mojarra implementation of navigationhandler doesn't find the machting rule when I send the query parameters, Ed Burns said and made an example (which is in the JSF 2 Original Reference and in post on blog https://blogs.oracle.com/enterprisetechtips/entry/post_redirect_get_and_jsf ) about the f:metada and f:viewParam, the Post-Redirect-get patterns, these seems awesome if it really works, here we go:
I'm using the Jboss AS 7.1.0.Final (cause the 7.1.1 cannot render pages correctly with composite components) and the provided impl is: "jsf-impl-2.1.5-jbossorg-1.jar"
I've debugged this implementation and the method determineViewFromActionOutcome in the NavigationhandlerImpl class, after find the exact/wildcard match, the implementation looks for the matching outcome which has the query params:
piece of method determineViewFromActionOutcome:
but, how you can see, it checks using equals method without substring the outcome in the first index of the char "?", I don't know if is this the correct way, what I have no doubts is that the implementation does not deal with this situation, thereafter I can't pass any parameters through implicit or explicit nagivation..
Is there some way to fix it?
Even if I make some work around , how can I say to jsf copy and pass these viewParams (which will match to the others in the destiny page)? It'll be complex to implement such a thing
thanks for everything
Whenever I get to feel this way, try to find new words to say.
I think about the bad old days, we used to know.
Nights of winter, turn me cold fears of dying getting old.
We ran the race, and the race was won. By running slowly...
JSF doesn't handle URLs the same way most webapp platforms do. For one thing. it does most of its work using HTTP POST, which means that (GET) query parameters are really best reserved for bookmarkable URLs, not for the general workflow processes. In fact, until Mojarra came along, query parameter support for JSF was mostly via brute force. JSF's architecture relies primarily on beans passing each other information behind the scenes on the server side rather than via the client.
As I've said often, the more JSF-specific your code is, the more likely it's doing things the hard way, since a primary design goal of JSF was to be as POJO as possible.
So rather than ask us how come your technical solution doesn't work, a better approach would be to tell us what the end goal is in terms of application functionality.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.