I've recently started thinking again how to better resolve the issues Kalle brings up in this previous thread: http://markmail.org/thread/ofk6dfavjn7wlafo
During my review of the code, it appears that our default WebConfiguration implementation is really just an unnecessary abstraction away from a normal Filter implementation. Because our implementation requires the FilterConfig object and then performs configuration steps based on FilterConfig values, the code feels like the logic that exists in most filters, as if it should just be in the KiFilter (or maybe an intermediate superclass) by default. That is, our implementation is very filter specific, and a separate instance doesn't buy us much in this case. My question - does it make sense to just have the KiFilter (or an intermediate superclass) do most of this stuff, and recommend integration components just subclass it? (e.g. SpringKiFilter, TapestryKiFilter, etc)? Typically I favor Composition over Inheritance, but it seems as if subclassing might make more sense here. Of course there could but SpringWebConfiguration and TapestryWebConfiguration implementations instead of subclassing the KiFilter, but if they have to work with FilterConfig objects and other related concepts, why not just subclass KiFilter? Then the one method in WebConfiguration would just be a protected method in the KiFilter. Thoughts? Les
