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
> >
>
