Just to clarify: that has also been as such _before_ Thomas has looked at it, so for several months this must have been working.
Blame marketing ;) ! regards, Martin On 7/8/05, Thomas Spiegl <[EMAIL PROTECTED]> wrote: > I took a look at the JspTilesViewHandler. It just has dependencies on shared > classes. > So the view handler is independend from the myfaces-implementation by now. > From there it should also run on any otherJSF implementation. > > > On 7/7/05, Sean Schofield <[EMAIL PROTECTED] > wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > >
