struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [shale] Configuring TilesViewHandler
Date Wed, 06 Jul 2005 21:28:02 GMT
On 7/6/05, Sean Schofield <> wrote:
> OK I got TilesViewHandler working by iteself (without
> ShaleViewHandler.)  It works great.  Nice work David.
> As for combining the two, I would recommend ShaleViewHandler extend
> TilesViewHandler.  The ViewHandler interface method that
> TilesViewHandler uses is renderView.  ShaleViewHandler just delegates
> the renderView method so we could just drop the method.

Actually, extending is *not* the recommended way to do this, because
it ties the implementations too tightly together.

> I'm curious as to how a JSF implmentation should handle multiple
> faces-config.xml files which both specify a <view-handler>.  I'm
> assuming the last one processed will "win."

It's not just an issue of "winning", although it is true that the last
<view-handler> that is processed is the "default" one for the

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.

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.

By the way, this same decorator pattern applies to pretty much all the
other extension points in JSF as well.  In every case, you can have as
many implementations of that extensibility interface that you like,
making it easy to combine JSF-based frameworks from multiple sources
(as long as they all play by the Decorator Pattern rules).  Just as an
example, that's how Shale implements dialogs -- a custom
NavigationHandler that comes into play *only* if you've purposely
entered a dialog, but just delegates to the previous implementation
(no matter where it comes from) otherwise.  That way, all the standard
JSF navigation continues to work, without having to be reimplemented. 
And the custom NavigationHandler does not have to depend on Shale
either -- only on JSF APIs (although in this particular case, you
would currently need to trigger the configuration yourself ... that's
pretty straightforward, though).

> sean


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message