[digester] named stacks

[robert burrell donkin <ro...@blueyonder.co.uk>]

i've been thinking about a user request to use the result of the method 
call in a CallMethodRule as a parameter in a subsequent call. most 
inter-rule communication in digester is done using stack. a rule instance 
pushes something onto a stack which is later popped off by another rule.

digester already has two stacks (the main one and the params one) together 
with accessor methods. but i'd say that adding more stacks like this will 
quickly become counterproductive. this strategy also limits the ability of 
users to create custom rules which communicate in the right way.

so, i'm thinking about adding a map of stacks indexed by strings which are 
lazily created on demand. this will be exposed by accessor methods which 
take a name string in addition to the rest. whenever new rules need to use 
a new stack, we add a key constant (probably starting with 
"org.apache.commons.digester") and then access the stack through the named 
stacks methods.

comments?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] named stacks

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Monday, July 14, 2003, at 01:08 AM, Simon Kitching wrote:

> Hi Robert,
>
>> From this email, I presume that your implementation of "pass return
> value of CallMethodRule as parameter to another CallMethodRule" requires
> another stack?

i have a few different ideas which could solve variations of this problem.

> Can you explain why the new stack is required?

a new stack would only be needed to solve the most general use case.

it would be pretty simple to provide an easy solution that pushes the 
result onto the main object stack and which a param could later read. the 
object would only available on the main object stack for child elements of 
the element to which the CallMethodRule was mapped. for example consider

<alpha><beta/></alpha><gamma/>

with the call method pusher mapped onto the alpha element. a param rule 
mapped to beta would be able to access the object but not a rule mapped to 
gamma.

another solution would be to alter the parameter stack when the call 
method is executed. this would work only when the parameter setting call 
method rule was mapped within the element to which the major call method 
rule was mapped. for example with

<alpha><beta/></alpha><gamma/>

this would work when the parameter setting call method was mapped to <beta>
  and the call method using the parameter was mapped to <alpha> but not 
when the parameter setting rule was mapped to <gamma>.

but i think that the most general use case requires an independent 
communication channel independent of the main object stack and the 
parameter stack. stacks feel like the right way to communicate for 
SAX-based applications. allowing a rule to push this onto an arbitrary 
named stack which another rule could pop off later seems to me like a good 
way to provide the most general form of this functionality.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] named stacks

[Simon Kitching <si...@ecnetwork.co.nz>]

Hi Robert,

>>From this email, I presume that your implementation of "pass return
value of CallMethodRule as parameter to another CallMethodRule" requires
another stack?

Can you explain why the new stack is required?


Thanks,

Simon


On Mon, 2003-07-14 at 05:08, robert burrell donkin wrote:
> i've been thinking about a user request to use the result of the method 
> call in a CallMethodRule as a parameter in a subsequent call. most 
> inter-rule communication in digester is done using stack. a rule instance 
> pushes something onto a stack which is later popped off by another rule.
> 
> digester already has two stacks (the main one and the params one) together 
> with accessor methods. but i'd say that adding more stacks like this will 
> quickly become counterproductive. this strategy also limits the ability of 
> users to create custom rules which communicate in the right way.
> 
> so, i'm thinking about adding a map of stacks indexed by strings which are 
> lazily created on demand. this will be exposed by accessor methods which 
> take a name string in addition to the rest. whenever new rules need to use 
> a new stack, we add a key constant (probably starting with 
> "org.apache.commons.digester") and then access the stack through the named 
> stacks methods.
> 
> comments?
> 
> - robert
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org