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