Why ist the DelegatingVariableResolver declared final? Until now, I subclassed the std. jsf VariableResolver to allow my detached hibernate objects to automatically get attached when accessed on my view. That worked perfectly. Now, with the new DelegatingVariableResolver I have to chance to subclass.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DelegatingVariableResolver isn't intended to be subclassed. Andy likes to state this by making the class final. If you've got evident reasons to subclass it, we might reconsider this.
Maybe you can achieve your functionality by delegation? VariableResolvers (like most other JSF components) are designed for delegation, meaning that you can implement a constructor with a parameter of type VariableResolver. This way, you'll be able to do your work and still effortlessly keep the original behaviour by delegating to the original VariableResolver. Furthermore, your code won't be implementation specific because it doesn't need to reference the specific VariableResolver implementation either from the JSF implementation used or from us.
HTH,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I did it after I realized that the jsf-spring VariableResolver is added programmatically instead of configuring it in the faces-config.xml. So now I do the same as jsf-spring - I wrap the "original" VariableResolver ;). Thanks for your reply.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
Why ist the DelegatingVariableResolver declared final? Until now, I subclassed the std. jsf VariableResolver to allow my detached hibernate objects to automatically get attached when accessed on my view. That worked perfectly. Now, with the new DelegatingVariableResolver I have to chance to subclass.
Any ideas?
DelegatingVariableResolver isn't intended to be subclassed. Andy likes to state this by making the class final. If you've got evident reasons to subclass it, we might reconsider this.
Maybe you can achieve your functionality by delegation? VariableResolvers (like most other JSF components) are designed for delegation, meaning that you can implement a constructor with a parameter of type VariableResolver. This way, you'll be able to do your work and still effortlessly keep the original behaviour by delegating to the original VariableResolver. Furthermore, your code won't be implementation specific because it doesn't need to reference the specific VariableResolver implementation either from the JSF implementation used or from us.
HTH,
Thomas
Yes, I did it after I realized that the jsf-spring VariableResolver is added programmatically instead of configuring it in the faces-config.xml. So now I do the same as jsf-spring - I wrap the "original" VariableResolver ;). Thanks for your reply.