[Jakarta-commons Wiki] Trivial Update of "Digester/FAQ/XmlRulesOrNotXmlRules" by SimonKitching

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Digester/FAQ/XmlRulesOrNotXmlRules

The comment on the change is:
minor tweaks only

------------------------------------------------------------------------------
  
  A number of books published about jakarta commons projects also recommend xmlrules.
  
- The original authors of the xmlrules project obviously thought it a good idea. However none of them have
- been involved in Digester development for many years now.
+ The original authors of the xmlrules project obviously saw sufficient advantages to make it
+ worth implementing the feature.
  
  == Opponents of xmlrules ==
  
- One digester developer (Simon Kitching) recommends avoiding the xmlrules module and staying with the standard java API
+ One digester developer (Simon Kitching) suggests avoiding the xmlrules module and staying with the standard java API
  for configuring rules. No other recent digester developer has expressed any opinion on this subject.
  
  === Simon's reasons for avoiding xmlrules ===
  
- I'm just not convinced it brings much benefit. When I first met digester, I started using the xmlrules module
- because it seemed to be the "highest abstraction". But in fact I found that the xml being parsed and the java classes
- that are being created/populated are conceptually tightly coupled anyway. There just isn't much need to change the 
+ While the xmlrules approach does indeed work, I'm just not convinced it brings much benefit. When I first met digester,
+ I started using the xmlrules module because it seemed to be the "highest abstraction". But in fact I found that the xml
+ being parsed and the java classes that are being created/populated are conceptually tightly coupled anyway. There just
- xml->class mapping unless the classes are being changed. And if the classes are being changed then it isn't really any
+ isn't much need to change the xml->class mapping unless the classes are being changed. And if the classes are being changed
- more work to change a mapping defined as code than to change a mapping defined in an external rules file.
+ then it isn't really any more work to change a mapping defined as code than to change a mapping defined in an external rules file.
  
  And anyone writing an application using digester will already be fluent in Java, so moving the mapping from code to 
  external xml file doesn't make life any easier that way. In fact, I think it makes things harder; I find the API easier
@@ -64, +64 @@

  And there are some features you just can't access via xmlrules. One example is passing references to arbitrary java 
  objects via the ObjectParamRule.
  
+ In addition, none of the original authors of the xmlrules module are still active in the project, so help with this
+ module may not be as readily available as support for the plain Java API.
+ 
  I can see xmlrules being useful in some situations. Maybe if writing some code-generation tool (eg from a UML diagram) 
  then it may be easier to generate xmlrules definitions than calls to the digester API.
  
  But in general, I think xmlrules is *harder to learn*, has runtime CPU and memory overhead, and brings no practical benefit.
  
  And one other thing: it is very easy to add custom Rule classes when using the API; it's somewhat more complex to do 
- so when using xmlrules.
+ so when using xmlrules (though not impossible).
  
  == Parsing xml files in multiple languages ==
  

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