commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From commons-...@jakarta.apache.org
Subject [Jakarta Commons Wiki] Updated: Digester/TODO
Date Tue, 25 May 2004 03:41:51 GMT
   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


Mime
View raw message