On 8/20/05, David G. Friedman <[EMAIL PROTECTED]> wrote: > Craig, > > I was actually referring to the class names. I was > confused by the use cases app which didn't list > the faces ViewHandler, NavigationHandler, etc. > Is there another working example which could show > me how those work? I only saw the use case using > the ShaleFilter, not the Shale JSF parts.
OK, I am sure I am too close to the forest to see the trees that you think are standing in your way :-), but there is likely to be a key feature of JSF that is leading to this question. A JSF implementation is *required* (by the spec) to recognize any "META-INF/faces-config.xml" resource in any JAR file under "/WEB-INF/lib" at app startup time. Among other things, this means that you can *transparently* register a custom ViewHandler (or whatever) without requiring any changes to the app's web.xml descriptor. Just inclue the appropriate JAR, and all the relevant registration occurs auto-magically. In relationship to Shale, then, you need to understand which of the JAR files include a "META-INF/faces-config.xml" resource, and what things those resources cause to be registered. Just as one example, the fact that "shale-core.jar" includes a "META-INF/faces-config.xml" resource explains how the event notifications for a ViewHandler are actually implemented. The beauty of the mechanism, of course, is that it works equally well for JSF component libraries that you might choose to include in your application -- the existence of an appropriate resource file inside the JAR triggers *automatic* registration of those components with the JSF runtime -- no custom web.xml settings are required. This kind of auto-registration of config files is available in a Servlet 2.3 (or later) environment, because that's where the ServletContext.getResourcePaths() method first became available. For JSF, that's not an issue since Servlet 2.3 is the minimum base platform. But it's definitely an issue for Struts 1.x, which has (at least through 1.2.x) depended solely on Servlet 2.2 facilities. > As for > why, I was wondering if Shale could work with FaceLets > but after reading the API which suggests using the > ShaleViewHandler, I'm doubting it since I don't > think JSF can use multiple ViewHandlers in one > webapp/JSF-config. > ViewHandler implementations, if they are properly designed, can be cascaded. Indeed, Shale already includes two such implementations (one for Tiles Standalone, and one for the ViewController event firing behavior). On the particular issue of Shale+Facelets, there is absolutely no reason they should *not* work together transparently -- that's the benefit of starting from a common base API. I can't endorse it as actually working, though, until I have had enough time to verify that for myself -- and gaps between international travel issues mean I might actually be able to play with this combination over the next couple of weeks. > Regards, > David > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
