Re: NavigationHandler registration
Wouldn't that get it registered last, rather than first? But yeah, you said at the bottom, that sounded to my like the last one added. however, a.jar or z.jar (whatever you want) can do the trick ;) either a z.jar or a.jar with nothing but a faces-config.xml declaring a nav handler may work. I'm not sure if that's better or worse than what I described above ;-) > doing something like this in a ServletContextListener is probably not > working, > b/c no rule how to specify the order (MyFaces has a CxtListener too) > > >NavigationHandler nh = > FacesContext.getCurrentInstance().getApplication().getNavigationHandler(); >NavigationHandlerImpl myNH = new NavigationHandlerImpl(nh); > > > FacesContext.getCurrentInstance().getApplication().setNavigationHandler(myNH); > Yeah, I'd need some mechanism to inject that code into the middle of MyFaces' initialization logic :-( L. > >> >> Thanks, >> >> L. >> >> > > -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: NavigationHandler registration
Matthias Wessendorf wrote: On 8/23/06, Laurie Harper <[EMAIL PROTECTED]> wrote: I have a requirement to register a custom NavigationHandler implementation at the bottom of the delegation stack, rather than at the top as happens when registering through WEB-INF/faces-config.xml. Basically, I need to make sure that delegating navigation handlers, such as Shale's DialogNavigationHandler, or the equivalent in Trinidad, delegate to my nav handler, *not* the other way around. Basically, my nav handler needs to replace MyFaces' default implementation, with the normal registration of delegating nav handlers from faces-config.xml files wrapping that. I know JSF (at least prior to 1.2, anyway) doesn't provide a mechanism to achieve this; does MyFaces? I know I can modify the standard-faces-config.xml file bundled in myfaces-impl.jar to get what I want (actually, that sets my nav handler up as the first delegating handler above MyFaces', but that's 'good enough' for my purposes). What i'd like, though, is a config option that would have the same effect. Alternatively, is there any other mechanism I can use to achieve this, MyFaces-specific or otherwise? you can put your nhImpl in a jar named zzz.jar and register the nh inside its' faces-config.xml Wouldn't that get it registered last, rather than first? But yeah, either a z.jar or a.jar with nothing but a faces-config.xml declaring a nav handler may work. I'm not sure if that's better or worse than what I described above ;-) doing something like this in a ServletContextListener is probably not working, b/c no rule how to specify the order (MyFaces has a CxtListener too) NavigationHandler nh = FacesContext.getCurrentInstance().getApplication().getNavigationHandler(); NavigationHandlerImpl myNH = new NavigationHandlerImpl(nh); FacesContext.getCurrentInstance().getApplication().setNavigationHandler(myNH); Yeah, I'd need some mechanism to inject that code into the middle of MyFaces' initialization logic :-( L. Thanks, L.
Re: NavigationHandler registration
On 8/23/06, Laurie Harper <[EMAIL PROTECTED]> wrote: I have a requirement to register a custom NavigationHandler implementation at the bottom of the delegation stack, rather than at the top as happens when registering through WEB-INF/faces-config.xml. Basically, I need to make sure that delegating navigation handlers, such as Shale's DialogNavigationHandler, or the equivalent in Trinidad, delegate to my nav handler, *not* the other way around. Basically, my nav handler needs to replace MyFaces' default implementation, with the normal registration of delegating nav handlers from faces-config.xml files wrapping that. I know JSF (at least prior to 1.2, anyway) doesn't provide a mechanism to achieve this; does MyFaces? I know I can modify the standard-faces-config.xml file bundled in myfaces-impl.jar to get what I want (actually, that sets my nav handler up as the first delegating handler above MyFaces', but that's 'good enough' for my purposes). What i'd like, though, is a config option that would have the same effect. Alternatively, is there any other mechanism I can use to achieve this, MyFaces-specific or otherwise? you can put your nhImpl in a jar named zzz.jar and register the nh inside its' faces-config.xml doing something like this in a ServletContextListener is probably not working, b/c no rule how to specify the order (MyFaces has a CxtListener too) NavigationHandler nh = FacesContext.getCurrentInstance().getApplication().getNavigationHandler(); NavigationHandlerImpl myNH = new NavigationHandlerImpl(nh); FacesContext.getCurrentInstance().getApplication().setNavigationHandler(myNH); Thanks, L. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
RE: NavigationHandler registration
I don't think myfaces allows it, but since you asked for an "alternative" you can use an AOP pointcut to intercept navigation dispatch. Remember though, this is a fairly low-level type of replacement and you should be careful not to break any interface contracts. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Laurie Harper Sent: Thursday, 24 August 2006 2:08 PM To: users@myfaces.apache.org Subject: NavigationHandler registration I have a requirement to register a custom NavigationHandler implementation at the bottom of the delegation stack, rather than at the top as happens when registering through WEB-INF/faces-config.xml. Basically, I need to make sure that delegating navigation handlers, such as Shale's DialogNavigationHandler, or the equivalent in Trinidad, delegate to my nav handler, *not* the other way around. Basically, my nav handler needs to replace MyFaces' default implementation, with the normal registration of delegating nav handlers from faces-config.xml files wrapping that. I know JSF (at least prior to 1.2, anyway) doesn't provide a mechanism to achieve this; does MyFaces? I know I can modify the standard-faces-config.xml file bundled in myfaces-impl.jar to get what I want (actually, that sets my nav handler up as the first delegating handler above MyFaces', but that's 'good enough' for my purposes). What i'd like, though, is a config option that would have the same effect. Alternatively, is there any other mechanism I can use to achieve this, MyFaces-specific or otherwise? Thanks, L. This correspondence is for the named persons only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis transmission. If you receive this correspondence in error please delete it from your system immediately and notify the sender. You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender except where the sender expressly, and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
NavigationHandler registration
I have a requirement to register a custom NavigationHandler implementation at the bottom of the delegation stack, rather than at the top as happens when registering through WEB-INF/faces-config.xml. Basically, I need to make sure that delegating navigation handlers, such as Shale's DialogNavigationHandler, or the equivalent in Trinidad, delegate to my nav handler, *not* the other way around. Basically, my nav handler needs to replace MyFaces' default implementation, with the normal registration of delegating nav handlers from faces-config.xml files wrapping that. I know JSF (at least prior to 1.2, anyway) doesn't provide a mechanism to achieve this; does MyFaces? I know I can modify the standard-faces-config.xml file bundled in myfaces-impl.jar to get what I want (actually, that sets my nav handler up as the first delegating handler above MyFaces', but that's 'good enough' for my purposes). What i'd like, though, is a config option that would have the same effect. Alternatively, is there any other mechanism I can use to achieve this, MyFaces-specific or otherwise? Thanks, L.
