| Rule implementation that sets properties on the object at the top of the
stack, based on child elements with names matching properties on that
object.
Example input that can be processed by this rule:
[widget]
[height]7[/height]
[width]8[/width]
[label]Hello, world[/label]
[/widget]
For each child element of [widget], a corresponding setter method is
located on the object on the top of the digester stack, the body text of
the child element is converted to the type specified for the (sole)
parameter to the setter method, then the setter method is invoked.
This rule supports custom mapping of xml element names to property names.
The default mapping for particular elements can be overridden by using
SetNestedPropertiesRule.SetNestedPropertiesRule(String[] elementNames,String[] propertyNames) .
This allows child elements to be mapped to properties with different names.
Certain elements can also be marked to be ignored.
A very similar effect can be achieved using a combination of the
BeanPropertySetterRule and the ExtendedBaseRules
rules manager; this Rule, however, works fine with the default
RulesBase rules manager.
Note that this rule is designed to be used to set only "primitive"
bean properties, eg String, int, boolean. If some of the child xml elements
match ObjectCreateRule rules (ie cause objects to be created) then you must
use one of the more complex constructors to this rule to explicitly skip
processing of that xml element, and define a SetNextRule (or equivalent) to
handle assigning the child object to the appropriate property instead.
Implementation Notes
This class works by creating its own simple Rules implementation. When
begin is invoked on this rule, the digester's current rules object is
replaced by a custom one. When end is invoked for this rule, the original
rules object is restored. The digester rules objects therefore behave in
a stack-like manner.
For each child element encountered, the custom Rules implementation
ensures that a special AnyChildRule instance is included in the matches
returned to the digester, and it is this rule instance that is responsible
for setting the appropriate property on the target object (if such a property
exists). The effect is therefore like a "trailing wildcard pattern". The
custom Rules implementation also returns the matches provided by the
underlying Rules implementation for the same pattern, so other rules
are not "disabled" during processing of a SetNestedPropertiesRule.
TODO: Optimise this class. Currently, each time begin is called,
new AnyChildRules and AnyChildRule objects are created. It should be
possible to cache these in normal use (though watch out for when a rule
instance is invoked re-entrantly!).
since:
1.6 | 