DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33001>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33001 ------- Additional Comments From [EMAIL PROTECTED] 2005-01-14 12:30 ------- >> I don't actually like xmlrules very much (at least in its current form). >Any comments on the form you'd like it to take? What about it do you dislike? >(The whole concept, or how it was implemented?) Well, I'm 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 xml->class mapping unless the classes are being changed. And if the classes are being changed 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 to comprehend than the xmlrules format. And certainly if you have any "bugs" in your mapping, then you really need to know how the rule classes work. So in summary, the learning curve is *worse* for learning xmlrules than for learning the underlying API. And it's a nuisance to maintain, because after adding a new feature to the API, you need to add it to xmlrules as well. And writing unit-tests for xmlrules is a nuisance too. And xmlrules has significant overhead when processing small input files, because the xmlrules file needs to be parsed first to set up all the rules. And there are some features you just can't access via xmlrules. One example is passing references to arbitrary java objects via the ObjectParamRule. I can see xmlrules being useful in some situations. If you want to provide configuration files in multiple languages, then it may make sense to use xmlrules, as it is probably easier to "internationalise" than code using the API. And 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. I'm playing with some ideas for "digester 2.0" at the moment. One thing I would like to do is make it easier to keep xmlrules in synch with the API; all those rule factory classes seem unnecessary to me. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
