Hi Robert,
From this email, I presume that your implementation of "pass returnvalue 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
