Howdy folks- I've just today noticed the classes/interfaces RequestedProperty RequestedProperties RequestedPropertyImpl RequestedPropertiesImpl PropertyName PropertyParseException
that have been added to our "main" package org.apache.slide.common. I hate to be a pain, but I have a couple of problems with the approach chosen. 1. The use of those classes is, AFAICT limited to the basicsearch implementation. Apart from the search package, only the content package has until now had a concept of properties (== NodeProperty). So IMHO the above classes should go either into search (preferred) or content. 2. The PropertyName, generally speaking, is a "(fully) qualified name" (i.e. bundling namespace and local name). However, there is already such a class in our repository: org.apache.util.QName. That class should be used and PropertyName removed, I think. 3. Both RequestedProperty and RequestedProperties are of such simple functionality, that splitting between interface and impl should not be necessary. I might be wrong here, but why should there ever exist a different implementation? Maintaining interfaces is trickier than maintaining classes, so the use of interfaces shouldn't be done without care. 4. The implementations of those classes have clear dependancies on the WebDAV protocol (i.e. by parsing the JDOM element). This is the probably most important problem I have with that code, and it could be easily removed (just let the WebDAV layer do the "parsing"). I believe that, as a general tendency, the separation between the kernel and the WebDAV layer has blurred quite a bit since work on the the new features has begun (for example, how do I access the versioning features without using the WebDAV code, or knowledge about Delta V, for example from the taglib?). This "blurring of the edges" has some serious impact on the overall architecture, so I think we should pay close attention to it. Thoughts, Comments? -- Christopher Lenz _______________________________________________ /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
