Hi! > 1) I have a managed-bean action-method which returns "overview" and > this means, I'll go to overview.jsp As long as you placed all your jsps in the root of your webapp this works nicely, you can check if there is a navigation rule and - if not, simply add .jsp and move to this view. But if you have a directory structure (like we have) things start to be not that nicely anymore, then you have to return something like "/my/view/dir/abc". You'll have to create a navigation rule with outcome "/my/view/dir/abc" .... this is not really nice. Maybe we can overcome this with an configurable "NavigationNameExtractor" which takes the last token of your view-Id to lookup a navigation rule.
But, to say the truth, even in an small application I wont use such a NavigationHandler. I like the decoupling of navigation and destination view too, THOUGH, I dont think that this decoupling allows someone to change the navigation "on the fly". In reality there is a dependency between two pages, there is a "silent" contract how to prepare the managed beans so that the destination page knows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff on the destination backing bean. And voilla, you'll have hard dependency between these two pages. Using a dialog or conversation scope here wont help much as the destination page (e.g. a search page) might participate in many different dialog or conversation scopes. At least, the "replaced destination view" has to use the same bean (or call it interface in this context) to determine which data to display. Said that, I wont use this new NavigationHandler, but I don't mind if we add it. Ciao, Mario
