On 9/26/06, Ingo Düppe <[EMAIL PROTECTED]> wrote:
You don't actually need to code a hard dependency on an implemenation of NavigationHandler. Pretty much all of the JSF extension points support the use of a "decorator pattern" so you can delegate behavior to the standard implementation, without knowing its class name. You'd do something like this:
public class MyNavigationHandler extends NavigationHandler {
private NavigationHandler original;
public MyNavigationHandler(NavigationHandler original) {
this.original = original;
}
public void handleNavigation(...) {
// Delegate to standard navigation handler
original.handleNavigation(...);
// Examine the new viewId to see if its ok
String newViewId = context.getViewRoot().getViewId();
if (isAcceptable(newVieId)) {
return;
} else {
... do something else ...
}
}
}
The key concept is that you provide a constructor that takes an instance of the API you are implementing. As JSF processes configuration files, it will pass in the previously configured version to your constructor.
Craig
I configured acegisecurity filter to listen on servlet forwards. But the
problem came from facelets, as soon I integrated facelets there were no
more forwards during the lifecycle :-(, so the security filter is not
informed about view changes. So I also decided to write a custom
navigation handler, but within the navigation handler you only have the
information about the current viewId and the outcome that was generated,
but nothing about the next viewId. Because that is the duty of the
navigation handler. And unfortunately there is no specification api
to figure out the next viewId and I didn't like to make a hardcoded
dependency to myfaces implementation to figure out that next viewId. So
I decided to implement a PhaseListener that backup the incoming viewId
in the early phases and if this viewId changed before the
render-response phase it make a redirect to the new viewId.
You don't actually need to code a hard dependency on an implemenation of NavigationHandler. Pretty much all of the JSF extension points support the use of a "decorator pattern" so you can delegate behavior to the standard implementation, without knowing its class name. You'd do something like this:
public class MyNavigationHandler extends NavigationHandler {
private NavigationHandler original;
public MyNavigationHandler(NavigationHandler original) {
this.original = original;
}
public void handleNavigation(...) {
// Delegate to standard navigation handler
original.handleNavigation(...);
// Examine the new viewId to see if its ok
String newViewId = context.getViewRoot().getViewId();
if (isAcceptable(newVieId)) {
return;
} else {
... do something else ...
}
}
}
The key concept is that you provide a constructor that takes an instance of the API you are implementing. As JSF processes configuration files, it will pass in the previously configured version to your constructor.
Regards
Ingo
Craig
