And all those things (delegation, chain to default view handler) are already implemented in the JspTilesViewHandler that Thomas has written months ago.
*sigh* We need better marketing... ;-) -Manfred 2005/7/7, Sean Schofield <[EMAIL PROTECTED]>: > > 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 >
