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 {@link #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.6Rule 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 {@link #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 | |
| |