commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration] New tree package
Date Thu, 29 Dec 2005 07:23:25 GMT
Emmanuel Bourg schrieb:
> Oliver Heger wrote:
> 
>> As I have promised, I plan to add support for XPATH queries to
>> (hierarchical) configurations. In a first step I did some polishing of
>> the Node class used internally by HierarchicalConfiguration; the current
>> way of storing child nodes and attributes made it very difficult to
>> efficiently select nodes based on queries. For this purpose I added a
>> new tree package, which ATM is somewhat experimental.
> 
> 
> Great! I looked quickly at the patch, some thoughts:
> 
> - ConfigurationNode, a shorter name would be better, but I don't have a 
> good alternative. We can't reuse "Node" since it's the name of the inner 
> class in HierarchicalConfiguration. Maybe the refactoring could be 
> pushed further by extracting HierarchicalConfiguration.Node and merging 
> it into the top level default Node implementation. This will break the 
> compatibility, but on the other hand the methods dealing with the nodes 
> are not frequently used by the final users.
Not sure about that. My intension was to keep compatibility - if 
possible. Perhaps we can deprecate some of the old stuff.

> 
> - Attributes: XMLConfiguration is the only hierarchical configuration to 
> expose attributes. What about moving the methods of ConfigurationNode 
> dealing with the attributes in the XMLNode implementation ? Unless an 
> attribute is defined as a child node with a value and no children ?
True, attributes are only used by XMLConfiguration. OTOH some query 
languages like XPATH have special concepts about them. When implementing 
such languages, I assume it will be easier if we don't need to 
distinguish by the node type; so I added the attribute methods to the 
interface.

> 
> 
>> Next thing I am going to do is extracting code that interprets property
>> keys from HierarchicalConfiguration.
> 
> 
> Do you plan to depend on an external library like jxpath ? If we could 
> keep it optional that would be nice.
I plan to introduce a concept like an ExpressionEngine (or QueryEngine?) 
that is used by hierarchical configurations. There will be a 
DefaultExpressionEngine that implements the property keys we have now.

If XPATH should be used, a specific XPathExpressionEngine must be set, 
which will depend on a library (probably jxpath - we should eat our own 
dog food ;-) So this new dependency will be completely optional.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message