I am definitely *not* looking at this right now (too much other stuff.) Also you are the expert :-)
sean On 7/7/05, Thomas Spiegl <[EMAIL PROTECTED]> wrote: > hi all, > > yes there are dependencies in JspTilesViewHandler that should get > eliminated. When i implemented TilesViewHandler i thought about moving all > needed resources to our shared library. > Sean, are you already working on this? If not, i could take a look at > MyFaces JspTilesViewHandler, fix the dependencies. > > regards, thomas > > > On 7/7/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Yes but the JspTilesViewHandler requires MyFaces implementation (for > > now.) Something I discovered very early on when playing with MyFaces. > > This is fixable but I can see why someone wanted to write one that > > worked with the RI. > > > > I was always under the impression that you could only use one > > user-supplied ViewHandler. That was why I was so keen on seeing > > David's added to Shale (which also has a view Handler.) I didn't > > realize he was going to write one that stands alone. That said, its a > > nice job. > > > > As the two projects mature we should revisit the idea of joining > > forces when it comes to pure JSF components that don't require Shale > > or MyFaces implementation. > > > > sean > > > > > > On 7/7/05, Manfred Geiler < [EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > >
