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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
