commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta Commons Wiki] Updated: Digester/TODO
Date Sat, 28 Aug 2004 11:10:30 GMT
   Date: 2004-08-28T04:10:30
   Editor: SimonKitching <>
   Wiki: Jakarta Commons Wiki
   Page: 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 
+Maybe the "named stacks" feature added in digester 1.6 can be used to solve this?
 == 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:
For additional commands, e-mail:

View raw message