commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33001] - [digester] Make <set-nested-properties-rule> available
Date Fri, 14 Jan 2005 11:30:45 GMT
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 skitching@apache.org  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message