Hi Christopher, first of all: sorry for the late response!! Many people were out all over the last month (vacations)!!
> 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. You are right. We will move them either to the search or to the content package. > 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. You are right. We didn't notice that class (...BTW, the class name "QName" is a bit odd IMO...). We will use that class instead of PropertyName. > 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. You are right. We will get rid of the interfaces and have just classes ... > 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"). ... and will do the parsing in extentions to that classes which will be located in the WebDAV layer. > 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? Well, as we stated in our initial "Proposal for adding DeltaV support to Slide", it was difficult to fully integrate DeltaV with the existing versioning engine in Slide-kernel. We therefore decided for a "semi-integrated" solution. As a compromise, we proposed to add a few additional helper methods in Slide API (e.g. content package) for accessing and navigating the DeltaV-specific history (...still to be done :-) ...). Regards, Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
