commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [Digester] HashMap on top of stack
Date Tue, 10 Feb 2004 22:37:14 GMT
On Wed, 2004-02-11 at 10:48, robert burrell donkin wrote:
> hi Christian
> i think that there are two general approach to solving this with  
> digester.

There is a third: Create a class "Definitions" which is a wrapper around
the HashMap:

public class Definitions {
  private HashMap defs = new HashMap();
  public void setNext(DefinitionBean db) { defs.put(db.getKey(), db); }
  public HashMap getMap() { return defs; }

You can then use the standard SetNextRule.

> the first is to create a custom Rule implementation. this should be  
> very easy in this case (just put the code you've already got into begin  
> and then get the ordering right).

Yep, creating a Rule to solve this specific problem shouldn't be hard. 
Digester is *designed* to allow users to add custom rules.

Christian: as Robert said, your pseudocode is pretty good already. You
really just need to declare a class extending Rule, then put your
pseudocode into the end() method. 

Note that digester.peek(0) returns top-of-stack (newest object), and
digester.peek(1) returns next-to-top (next-to-newest) object; this is
probably tidier than your pseudocode which used pop() and push().

> the second is to use a adapted version of CallMethodRule which calls a  
> method on the root object (rather than the top). this should be easy to  
> do and probably should already by in digester. (anyone fancy  
> volunteering to develop this one for the ASF?)

This doesn't sound too difficult - I'll have a stab at creating a
suitable class tonight.

It seems that what is needed is something like SetNextRule (which builds
parent/child relationships) except that the params need to be more
flexible - not just the object on top of the stack.

I suggest creating a "CallNextMethodRule" which behaves identically to
CallMethodRule except the target object is grabbed with peek(1) rather
than peek(). Obviously copy/paste should be avoided, so a "strategy" or
"template method" or similar approach could be used to "extend" the
existing CallMethodRule functionality to allow selecting the target
object from locations other than top-of-stack.

I think it would be nice to just add a "target object offset" param to
the CallMethodRule constructor (default value=0) to select the target
object on the stack, but there are so many constructors on
CallMethodRule already :-(

Any comments, Robert?



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

View raw message