Extension of {@link RulesBase} for complex schema.
This is an extension of the basic pattern matching scheme intended to improve support for mapping complex xml-schema. It is intended to be a minimal extension of the standard rules big enough to support complex schema but without the full generality offered by more exotic matching pattern rules.
This pattern-matching engine is complex and slower than the basic default RulesBase class, but offers more functionality:
The default RulesBase pattern-matching engine always attempts to find the "best matching pattern", and will ignore rules associated with other patterns that match but are not "as good". As an example, if the pattern "a/b/c" is associated with rules 1 and 2, and "*/c" is associated with rules 3 and 4 then element "a/b/c" will cause only rules 1 and 2 to execute. Rules 3 and 4 do have matching patterns, but because the patterns are shorter and include wildcard characters they are regarded as being "not as good" as a direct match. In general, exact patterns are better than wildcard patterns, and among multiple patterns with wildcards, the longest is preferred. See the RulesBase class for more information.
This feature of preferring "better" patterns can be a powerful tool. However it also means that patterns can interact in unexpected ways.
When using the ExtendedBaseRules, any pattern prefixed with '!' bypasses the "best match" feature. Even if there is an exact match or a longer wildcard match, patterns prefixed by '!' will still be tested to see if they match, and if so their associated Rule objects will be included in the set of rules to be executed in the normal manner.
"!*/a/b" matches whenever an 'b' element is inside an 'a'."!a/b/?" matches any child of a parent matching "a/b" (see "Parent Match Patterns")."!*/a/b/?" matches any child of a parent matching "!*/a/b" (see "Parent Match Patterns")."!a/b/*" matches any element whose path starts with "a" then "b" (see "Ancestor Match Patterns")."!*/a/b/*" matches any elements whose path contains 'a/b' (see "Ancestor Match Patterns").These will match direct child elements of a particular parent element.
"a/b/c/?" matches any child whose parent matches "a/b/c". Exact parent rules take precedence over Ancestor Match patterns."*/a/b/c/?" matches any child whose parent matches "*/a/b/c". The longest matching still applies to parent matches but the length excludes the '?', which effectively means that standard wildcard matches with the same level of depth are chosen in preference.These will match elements whose parentage includes a particular sequence of elements.
"a/b/*" matches any element whose path starts with 'a' then 'b'. Exact parent and parent match rules take precedence. The longest ancestor match will take precedence."*/a/b/*" matches any elements whose path contains an element 'a' followed by an element 'b'. The longest matching still applies but the length excludes the '*' at the end. Pattern "*" matches every pattern that isn't matched by any other basic rule.
Pattern "!*" matches every pattern.
By default, a Digester instance uses a {@link RulesBase} instance as its pattern matching engine. To use anExtendedBaseRules instance, call the Digester.setRules method before adding any Rule objects to the digester instance:
Digester digester = new Digester(); digester.setRules( new ExtendedBaseRules() );
The most important thing to remember when using the extended rules is that universal and non-universal patterns are completely independent. Universal patterns are never affected by the addition of new patterns or the removal of existing ones. Non-universal patterns are never affected by the addition of new universal patterns or the removal of existing universal patterns. As in the basic matching rules, non-universal (basic) patterns can be affected by the addition of new non-universal patterns or the removal of existing non-universal patterns, because only rules associated with the "best matching" pattern for each xml element are executed.
This means that you can use universal patterns to build up the simple parts of your structure - for example defining universal creation and property setting rules. More sophisticated and complex mapping will require non-universal patterns and this might mean that some of the universal rules will need to be replaced by a series of special cases using non-universal rules. But by using universal rules as your backbone, these additions should not break your existing rules.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |