commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject RE: [Digester] Parent Reference Help
Date Tue, 31 Aug 2004 23:24:56 GMT
On Wed, 2004-09-01 at 01:52, Ken Egervari wrote:
> Actually, Simon, this is precisely along the track that I need to go.  Thank
> you so much for suggesting this as I'm still a bit new to the digester.  
> However, I'm still having some problems with this approach, mainly that
> rules are being called prematurely and maybe that's why it was placed in
> end() in the first place.  
> In my case, the setters are still not being called, but this time it is
> because SetNextRule or SetTopRule is calling setParent() or addChild()
> before the child's properties have been set.  For example, if addChild() is
> called, the child's properties might be needed at this point (in my case,
> they do) and thus it adds a child with all null references.  While they
> might be filled with values afterwards, they need values when addChild() is
> called.

Hi Ken,

If you are using:

  digester.addObjectCreate("page/selectone", SelectOne.class);

then the setter methods on the SelectOne instance will be called before
the Page object's addChild method is called.

If you are using CallMethodRule rules to call methods on the SelectOne
object, then you have to add the rules to the digester in reverse order,
for reasons explained in a FAQ entry I have just created

> Usually people put default values for unspecified attributes or elements to
> avoid the null values but that isn't possible for required attributes like
> controller class name in my case since they cannot be assumed by default.
> Since the digester is inherently aware of XML, it should be aware of
> optional and required attributes and put the objects in a state that is
> consistent with the semantics of valid XML document.  Now, it doesn't need
> to be aware of the DTD, but it can at least try to populate values before
> these methods are invoked.  It's not something the user should have to worry
> about I don't think.  Fortunately, achieving this functionality is probably
> not that hard since your framework is already very flexible and it's
> probably a matter of defining higher-level sets of rules that people can use
> while the existing software is being used under the hood.

As described in the FAQ entry, setting object properties from xml
attributes (using the SetPropertiesRule) should "just work" (tm).

Setting object properties using CallMethodRule has slightly unintuitive
behaviour wrt SetNextRule, but it can be done. Removing the quirk is
unfortunately very difficult; it is pretty much due to the nature of
stacks, and the concept of stacks is at the very core of Digester. So we
generally just live with the slightly odd workaround required (see the

Thanks for your positive feedback, and I hope the FAQ entry solves your
problem. If it doesn't, please feel free to email again.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message