commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Leboeuf <martin.lebo...@mail.mcgill.ca>
Subject Re: [Digester 1.4.1] <set-next-rule /> question
Date Tue, 25 Mar 2003 14:11:06 GMT
Hi !

It did help! Thanks a lot!

M.

Simon Kitching wrote:
> Hi Martin,
> 
> You should be able to get the effect you want by moving the
> set-next-rule to *before* the call-method-rule.
> 
> A rule can perform operations when:
> (a) the start of a tag is encountered [begin method on Rule], or
> (b) when the end of a tag is encountered [end method on Rule].
> 
> The begin() method of different rules are invoked in the order that the
> rules are defined; the end() methods are invoked in the reverse order.
> This is necessary because rules are manipulating a stack. 
> 
> Example:
> 
>  RuleA declared for pattern "a/b"
>  RuleB declared for pattern "a/b"
> 
>  when a/b is matched, methods are invoked as follows:
>    RuleA.begin()
>    RuleB.begin()
>    RuleB.end()
>    RuleA.end()
> 
> 
> SetNextRule rules do nothing on begin, and invoke the target method on
> the parent object on the stack when end() is called.
> 
> CallMethodRules also do nothing on begin and invoke the target method on
> end. 
> 
> So if you declare a CallMethodRule followed by SetNextRule, you get:
>   CallMethodRule.begin() --> does nothing
>   SetNextRule.begin() --> does nothing
>   SetNextRule.end() --> invokes method on parent
>   CallMethodRule.end() --> invokes method on top object
> 
> but if you declare a SetNextRule followed by a CallMethodRule, you
> should get what you want.
> 
> Yes, it is a little odd, but calling the end() methods of rules in the
> same order as they were declared (rather than reverse order) would stuff
> up the stack for any rule which pushes/pops objects on the stack, like
> ObjectCreateRule.
> 
> Hope this helps,
> 
> Regards,
> 
> Simon
> 
> On Tue, 2003-03-25 at 02:45, tslusser@InPhact.com wrote:
> 
>>It appears that the method (defined in set-next-rule) is called immediately
>>after the object (defined in object-create-rule) is instantiated.  This
>>means setLSID is called after setMarker.  Don't know why.  I agree that it
>>seems logical the setMarker should be called after all of the methods,
>>attribute setters, etc are called.
>>
>>-----Original Message-----
>>From: Martin Leboeuf [mailto:martin.leboeuf@mail.mcgill.ca]
>>Sent: Monday, March 24, 2003 8:40 AM
>>To: commons-user
>>Subject: [Digester 1.4.1] <set-next-rule /> question
>>
>>
>>Hi !
>>
>>I am using Digester 1.4.1 to parse xml documents. I am defining my rules 
>>in an xml document instead of programmatically. Based on my 
>>understanding of the documentation, the method defined in the 
>><set-next-rule> element is typically used to insert a completed bean 
>>into its parent. Therefore, it should be called when the bean is 
>>completed i.e. when other method calls defined on that bean have been 
>>performed. Here is an excerpt of my xml rules file:
>>
>>   <pattern value="batch">
>>     <object-create-rule classname="my.package.xml.XMLMarker"/>
>>     <pattern value="snps/snp">
>>       <object-create-rule classname="my.package.Marker"/>
>>       <call-method-rule methodname="setLSID" paramcount="1"/>
>>       <call-param-rule attrname="lsid" paramnumber="0"/>
>>       <set-next-rule methodname="setMarker"/>
>>
>>When the setMarker method is called on the XMLMarker object, the setLSID 
>>method has not yet been called on the Marker object. As I just 
>>explained, my expectation was that it would have been. What am I 
>>missing/misunderstanding?
>>
>>Thanks,
>>
>>Martin.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 



Mime
View raw message