> Actually, extending is *not* the recommended way to do this, because > it ties the implementations too tightly together.
I agreed this is to be avoided but I wasn't aware that its possible to chain the ViewHandlers. [snip] > The key is that each implementation of ViewHandler should have a > constructor that takes a ViewHandler argument. As the JSF runtime is > processing configuration files, it should be checking whether such a > constructor exists. If it does, the runtime will call *that* > constructor (passing in the most recent "default" implementation) so > that you can construct a *chain* of implementations that can add > specialized behavior where relevant, or delegate to the previous > implementation for all the regular use cases. That changes things then. I was reading up on ViewHandler but everything I read kept mentioning that the "default" implementation would be passed. It wasn't clear that the meaning of "default" was really "default as decorated so far." A chain was what I was going to suggest for a spec revision but it appears that this has already been anticipated ;-) > Separating the two implementations allows a Shale user who is *not* > using Tiles from having to pay any overhead at all for the fact that > shales-tiles.jar is available (although, not in this webapp, > obviously). It also means that shale-tiles.jar (the interface layer) > will have *zero* dependencies on Shale -- at least, once I clean up > the localization thing -- so it can be used (with MyFaces or any other > JSF implementation) without the rest of Shale. I agree that you would want the ability to use TilesViewHandler without the rest of Shale, that's why I figured ShaleViewHandler would extend TilesViewHandler instead of the other way around. Turns out extension is not needed. An interesting aspect of the decorator/chain pattern is that you need to know a little bit about the internals of the ViewHandlers that your are chaining together. Its possible that there could be a conflict between two ViewHandlers that want to do two different things in the same interface method. Also, I can envision situations where the order of decoration might be important (not this case though.) [snip] Thanks for the clarifying this. sean
