+1 (non-binding) on making sure all the components in Tomahawk work on the RI (or, for that matter, any other JSF implementation. That's part of the whole idea of a common API standard.
That being said, I'm not sure it's really as bleak a prospect as some might be concerned about. In particular, if something like the MyFaces support for Tiles needs a custom JSF ViewHandler, then make that implementation (a) well behaved with respect to delegating to the standard version when the specified view is *not* a tile, and (b) include this ViewHandler implementation in the component library with a META-INF/faces-config.xml file that registers it. This way, you should still be able to run the custom view handler on top of anyone's JSF runtimes ... simply by following the extensibility design patterns that JSF provides. You might want to take a glance at the Tiles integration code (to the standalone version of Tiles in the Struts Sandbox) for Shale that David Geary committed a couple of nights ago. It follows exactly this sort of pattern, but contains no dependencies on private implementation classes in the underlying JSF runtime. So, it'll work on top of either the RI or MyFaces. Interestingly, this code (like most of the other optional integrations in Shale) is almost totally independent of the rest of Shale (there's a small dependence on a util class for localization, which could be worked around by using resource bundles directly). We'll probably want to come back around to the topic of where small, JSF-implementation-independent things like this can be managed and released in a fine grained way, so you can pick and choose just the parts you want. Craig On 7/6/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > This proposal might be a bit controversial... > > I think we should make everything in tomahawk 100% RI compliant and > remove anything that is not. We've made (eroneous) claims in the past > that the stuff in the old components.jar will work with the RI but > there are several exceptions. I think we can get broader > usage/acceptance of the tomahawk stuff if we can legitimately claim > that it works with any implementation. > > Rather than dumping everything that does not currently work with the > RI, I recommend we move it to the sandbox and perhaps resurrect it > when we have the time/interest. There are a few components that have > minor RI quirks that I think we can leave in tomahawk but address them > ASAP. Other components/extensions have outright dependencies on the > myfaces implementation. > > One major component that should be moved out of tomahawk (IMO) is > tiles. Let me start by saying that I like the Tiles stuff and it is > one thing that attracted me to MyFaces. But it requires the MyFaces > implementation (uses some view controller stuff.) We could refactor > it but I am not volunteering for that. If someone else is prepared to > refactor then I say leave it in tomahawk an refactor. If not, lets > move it to sandbox. > > David Geary (Tiles guru) just checked in some JSF Tiles support into > the Shale project. If we dropped Tiles from tomahawk (and sandbox) > that might not be the end of the world. > > There are other components as well that are not RI compliant. We > should make a list and figure out what we want to do with them. At a > *minimum* we should list the stuff in tomahawk that does *not* work > with the RI and publicize that list. > > sean >
