On Wed, 2005-12-21 at 09:32 +0000, robert burrell donkin wrote: > On Tue, 2005-12-20 at 18:10 +0100, Valerio Schiavoni wrote: > > > > What I mean is: how can I istantiate 'immutable' objects that requires > > values in their constructors ? None of the examples I found illustrate this > > situation, so maybe this is voluntarly not supported by api designers. if > > so, it'be interesting to understand why. > > digester can do what you want but AFAIK there is no standard rule > suitable for your exact problem (if anyone knows of one, please jump > in). FactoryCreateRule can be used when the required initialization > parameters are contained in attriutes. > > you can easily solve your particular problem by creating a custom rule. > if you feel like contributing a more general solution that can be > included in the standard rules, let me know and i'll outline a design.
Unfortunately I suspect this is not at all easy to do with Digester. It's an issue that's been in the back of my mind for ages, and I've got no clean solution for it. As Robert says, creating components from the attributes is easy - FactoryCreateRule does this, or a custom rule is easy to write. Creating a new instance based upon nested tags is not trivial though. It *might* be possible but you would be breaking new ground; I'm not aware of anyone having implemented this with Digester yet. Maybe something like CallMethodRule could be used, but where it invokes java.lang.Constructor.newInstance(args) then pushes the object onto the stack. Tricky, though, as the object needs to remain on the stack long enough for something like a SetNextRule to operate on it, but must be removed from the stack before the matching element ends in order for correct object stack behaviour to occur. The prototype CallMethodRule I implemented which fired as soon as all parameters were available might help there; the rule could push a dummy object on begin which is replaced when all params are available, and the rule's end method could then pop it off. However that CallMethodRule variant has not yet made it into trunk. A cooperating pair of rules could do the same job: a rule that just pushes a dummy object on begin and removes it on end, then a separate rule that creates the desired object and *replaces* the top object on the stack with it. That's rather ugly though, both in implementation and in use. Combining the construction rule with a SetNextRule would be much easier to implement: in the end method the rule can create the object using param objects stored by CallParamRule instances, and immediately invoke the SetNextRule-like functionality to add the object to a parent without ever needing to put the created object on the digester object stack. I think that solves the problems listed above, but at the cost of a significant loss of flexibility. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
