[Jakarta Commons Wiki] Updated: Digester/TODO

[co...@jakarta.apache.org]

   Date: 2004-08-28T04:10:30
   Editor: SimonKitching <si...@ecnetwork.co.nz>
   Wiki: Jakarta Commons Wiki
   Page: Digester/TODO
   URL: http://wiki.apache.org/jakarta-commons/Digester/TODO

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -56,6 +56,19 @@
 
 Move to jira as the bug tracking repository?
 
+=== Add Rule to map body text to property named in attribute ===
+
+There have been a number of questions on the user list about how to parse the following style of xml:
+  <property name="txtNumClient">num1</property>
+
+This seems a good candidate for a new rule. However implementation is a little tricky, because the name 
+of the destination property is specified in a different SAX callback than the data to be assigned to that 
+property. 
+
+Maybe the "named stacks" feature added in digester 1.6 can be used to solve this?
+
+See: http://www.mail-archive.com/commons-user@jakarta.apache.org/msg07607.html
+
 == Possible ==
 
 === Refactor CallParamRule ===
@@ -108,6 +121,21 @@
 === Rule to pass xml attributes as a Map ===
 
 Create a new rule which gathers all the xml attributes into a Map object and passes this as a parameter to a method. Possibly this could be an extension to the existing !CallParamRule, but that rule has so many options already!
+
+=== Allow Rule objects which are not intended to be nested to store state? ===
+
+In general, Rule objects are not allowed to store any "state" in the members of an instance, where "state" means data that changes during parsing of a document.
+The reason is that when associated with patterns involving wildcards, or where a single rule instance is associated with multiple different patterns, 
+rule objects can be invoked in a "nested" manner, with their methods being invoked in the order "begin (begin body end) body end". Clearly such an invocation 
+pattern doesn't work if the object is storing state on itself (unless it uses stacks).
+
+However some rules clearly can't sensibly be invoked in a nested manner, eg !SetPropertyRule.
+
+So maybe it would be sensible to allow state to be stored on some rules, provided they use an assertion or similar to prevent themselves from
+ever being used in a "nested" manner.
+
+Consideration needs to be given, though, to resetting the state if a parse fails part-way through, or if a Rule instance is stored in a !RuleSet and
+added to multiple Digester instances, etc.
 
 = Version 2.0 =
 

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