[Jakarta Commons Wiki] Updated: Digester/TODO

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

   Date: 2004-05-24T20:41:51
   Editor: 202.135.190.30 <>
   Wiki: Jakarta Commons Wiki
   Page: Digester/TODO
   URL: http://wiki.apache.org/jakarta-commons/Digester/TODO

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -2,8 +2,7 @@
 
 This page lists a bunch of ideas which may or may not be implemented in future releases of the Digester.
 
-If the idea seems to have definite advantages, and seems to have a reasonably obvious implementation, then it should
-go into the "probable" section. If the idea is only tentative then it should go into the "possible" section.
+If the idea seems to have definite advantages, and seems to have a reasonably obvious implementation, then it should go into the "probable" section. If the idea is only tentative (or if it is likely to be controversial) then it should go into the "possible" section.
 
 = Version 1.7 =
 
@@ -11,18 +10,18 @@
 
 === InvokeMethodRule ===
 
-Evaluate the {{{InvokeMethodRule}}} code that is currently committed to CVS on a branch.
-This new rule acts like {{{CallMethodRule}}} except that it calls the target methods as soon as all the necessary parameters are available. 
-This is much more intuitive in a number of scenarios; the code is a fair bit more complicated than {{{CallMethodRule}}} however.
-The API for this new rule is also much cleaner than {{{CallMethodRule}}}, which has gathered cruft as new features have been added.
+Evaluate the !InvokeMethodRule code that is currently committed to CVS on a branch.
+This new rule acts like !CallMethodRule except that it calls the target methods as soon as all the necessary parameters are available. 
+This is much more intuitive in a number of scenarios; the code is a fair bit more complicated than !CallMethodRule however.
+The API for this new rule is also much cleaner than !CallMethodRule, which has gathered cruft as new features have been added.
 
 === handling hyphenated properties ===
 
-It would be nice for {{{SetProperties}}} and {{{SetNestedProperties}}} rules to automatically map xml attributes and element names like "foo-bar" to bean properties of form "fooBar". The hyphenated naming style is a very common xml usage, but is currently very difficult to handle within Digester.
+It would be nice for !SetProperties and !SetNestedProperties rules to automatically map xml attributes and element names like "foo-bar" to bean properties of form "fooBar". The hyphenated naming style is a very common xml usage, but is currently very difficult to handle within Digester.
 
 === SetPropertyRule from element body ===
 
-Implement a {{{SetPropertyRule}}} variant that allows the data to be in the body text.
+Implement a !SetPropertyRule variant that allows the data to be in the body text.
 
 === Example code onto digester website ===
 
@@ -38,7 +37,7 @@
 
 === Variable Expansion and Ant ===
 
-Look into whether the {{{Substitutor}}}/{{{MultiVariableExpander}}} framework satisfies Ant's requirements for xml parsing. 
+Look into whether the !Substitutor/!MultiVariableExpander framework satisfies Ant's requirements for xml parsing. 
 
 The Substitution framework and variable expansion facilities were added during the 1.6 release. It would be nice to confirm that anything ANT variables can do can also be handled using this framework.
 
@@ -53,7 +52,7 @@
 == Possible ==
 
 === Refactor CallParamRule ===
-Refactor the {{{CallParamRule}}} to break out the separate pieces of functionality into separate rules. Perhaps give them a consistent naming standard, like: "CallParamWithXXXRule".
+Refactor the !CallParamRule to break out the separate pieces of functionality into separate rules. Perhaps give them a consistent naming standard, like: "CallParamWithXXXRule".
 
 === AccessController and Private Methods ===
 
@@ -97,7 +96,7 @@
 
 How could we implement this in Digester? It is almost the same as setting pattern "*", because that will only match if it is the longest match. But all of the "implicit" rules would fire, whereas Joran only fires the first "applicable" implicit rule. I think this "one implicit rule only" is a little app-specific, but it works for them and the end result is quite effective.
 
-The {{{WithDefaultsRulesWrapper}}} class is also similar to this. Does anyone have any examples of when {{{WithDefaultsRulesWrapper}}} would actually be useful?
+The !WithDefaultsRulesWrapper class is also similar to this. Does anyone have any examples of when !WithDefaultsRulesWrapper would actually be useful?
 
 = Version 2.0 =
 
@@ -127,7 +126,7 @@
 
 Separating the user API from the rule API might be a little trickier, but would be beneficial too. There is no reason why a *user* of the digester should be required to wade through an API including push() and pop() methods. Yes, push() is currently used to "prime" the stack before parsing in some cases, but a method like "setInitialObject(x)" would be a much nicer method to expose to users (it would call push(x) internally).
 
-Joran uses "Interpreter" --> "SaxHandler", and "ExecutionContext" --> "Digester" sans "SaxHandler", with "ExecutionContext.getHandler" to get the saxhandler if necessary.
+Joran uses "Interpreter" --> "!SaxHandler", and "!ExecutionContext" --> "!Digester" sans "!SaxHandler", with "!ExecutionContext.getHandler" to get the saxhandler if necessary.
 
 === Define Rule Lifecycle methods ===
 
@@ -142,7 +141,8 @@
 It would be nice to define more formally what exceptions Rule objects can throw and when. The plugins module, for example, has to jump through some hoops to handle potential error cases.
 
 === Remove deprecated methods ===
-{{{xmlrules.DigesterRuleParser}}} uses the deprecated begin() and end() methods (as do some other rules). Fix these. In general, get rid of use of deprecated methods.
+
+Class !DigesterRuleParser in the xmlrules package uses the deprecated begin() and end() methods (as do some other rules). Fix these. In general, get rid of use of deprecated methods.
 
 == Possible ==
 
@@ -150,7 +150,7 @@
 
 Provide "mini-digester" distribution? This could contain:
  * Digester "core" class (without factory methods)
- * Only {{{RulesBase}}} rules engine
+ * Only !RulesBase rules engine
  * No plugins or xmlrules
 
 
@@ -163,14 +163,14 @@
 === Rename classes ===
 
 Here are some possible name improvements:
-* rename "Rules" --> "RuleEngine" or "RuleMatcher" or "RuleManager"
-* rename "Rule" --> "Action"?
+ * rename "Rules" --> !RuleEngine or !RuleMatcher or !RuleManager
+ * rename "Rule" --> "Action"?
 
 === Allow only single instance of a Rule ===
 Forbid a single Rule instance from being added to a digester more than once? This allows a rule to store context info in its members rather than jump through hoops to store that info on various stacks. (or does it, when pattern = "*/foo"?)
 
 === CallMethodRule interleaving issue ===
-Fix nasty problem with {{{CallMethodRule}}} where interleaved instances of this rule can mix up their parameter stacks.
+Fix nasty problem with !CallMethodRule where interleaved instances of this rule can mix up their parameter stacks.
 
 === XPath-like patterns ===
 Provide more xpath-like patterns by default, eg:
@@ -192,7 +192,7 @@
 === Enhance Exceptions ===
 Provide more declared exceptions on various methods
 
-Have Digester guarantee to catch a certain subclass of RuntimeException (eg "DigesterTunnelledException"), so that we can future-proof the system against new situations where we want to throw an exception but the interface doesn't allow us.
+Have Digester guarantee to catch a certain subclass of !RuntimeException (eg !DigesterTunnelledException), so that we can future-proof the system against new situations where we want to throw an exception but the interface doesn't allow us.
 
 === Logging Improvements ===
 Fix ugly logging mess. The apparent requirement is that container apps want to be able to instantiate multiple digester objects in the same classloader, but configure their logging differently. Confirm this requirement first.
@@ -205,9 +205,9 @@
 See the ruby xmldigester (http://rubyforge.net/xmldigester) implementation for an example.
 
 
-=== Xmlrules automatic handling of new Rule classes ==
+=== Xmlrules automatic handling of new Rule classes ===
 Fix problem where xmlrules needs to be manually updated when new rules/features are added to the digester "core". Ideally, xmlrules would "auto-detect" rules/features at runtime. However an XDoclet approach that generated the appropriate xmlrules stuff at compile-time would still be an improvement.
 
 === Pop and Peek should throw EmptyStackException ===
-Digester.pop() and peek() should throw EmptyStackException. Currently they return null when empty.
+Digester.pop() and peek() should throw !EmptyStackException. Currently they return null when empty.
 

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