To me this sounds like a reasonable idea. Maybe for Digerter 2? Simon? What do you think?
Oliver On Sun, 10 Oct 2004 13:23:46 +0200, Daniel Florey <[EMAIL PROTECTED]> wrote: > Hi, > > Wouldn't it be possible to create a xmlio callback-handler that invokes the > digester rule-matcher? So that we can finally get the best of the two > approaches: Keep a very slim jar containing just the xmlio/in sax > augmentation part and call it digester-core.jar or however and an additional > digester-rules.jar that contains the rule-specific callback handler and > enables all the digester add-ons? > See my comments inline > Regards, > > Daniel > > > -----Urspr�ngliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Im Auftrag von Simon Kitching > > Gesendet: Sonntag, 10. Oktober 2004 11:04 > > An: [EMAIL PROTECTED] > > Betreff: [xmlio] comparison with Digester > > > > Hi, > > > > I've had a look at the new "xmlio" code in the sandbox; below is my > > initial opinion. Note that I am a committer on Digester, and am > > therefore totally biased.... > > > > The "in" code that is used to parse input xml documents is really really > > similar in concept to what Digester already does. > > > > The main features appear to be: > > (a) > > A "callback handler list" (instead of a single ContentHandler object). > > > > Well, this seems to me to be equivalent to the Digester concept of > > having multiple Rule objects match a particular input element, ie > > several distinct sections of code can all be triggered when a particular > > element is matched. > > This callbackhandler-list is very useful to temporarily add a > logging-handler for debugging purposes. > > > > > (b) > > A complete path to the current element is passed to the "startElement" > > method. > > > > Digester has the "getMatch" method which can be called by any rule to > > get the path to the current element. Xmlio does provide a SimplePath > > instance instead of a plain string to represent this path (equivalent to > > the File class wrapping a filename). However in Digester you don't > > really need anything more complex than a string because you don't > > normally do computations on paths anyway - you leave that up to the > > "rule matcher" class. > > The SimplePath class is very useful if you deal with multiple namespaces. > How is this represented in digester in a simple string? > > > > > (c) > > The xmlio concept of having a callback method invoked at element end > > which passes both the element text and the element attributes is mildly > > useful (but calling this method "startElement" is rather confusing IMO). > > It would certainly be possible to add this feature to Digester/Digester2 > > (though it does have a minor performance drawback). With the current > > digester code, you can clone the attrs and push them on a (named) stack > > in begin() and then fetch them back in body() to get the same effect. > > Working with stacks is complicated especially for Java beginners. So I'd > like to see this ability in the core parsing jar that will make it. IMO > simplicity in use is the main goal for the parsing core. > I think it should be no problem to rename methods if we find better > wordings. > > > > > > > > > My initial feeling, therefore, is that I would much rather see > > additional work put into the Digester project than having this new xmlio > > project essentially recreate a subset of Digester functionality. > > > > The main problem with Digester, I think, is that it has nasty > > inter-class dependencies that prevent subsets of the classes from being > > distributed. Every Rule class depends upon the Digester class, which > > provides "parse context". But the Digester class has factory methods for > > all the rules - so Digester can't be distributed without including *all* > > the Rule classes. Breaking this dependency is number one priority for > > Digester2 as far as I am concerned. It isn't that hard to do; I've been > > experimenting with various refactorings already. > > > > I would love to see several jar files built from the Digester2 source: a > > "src" distro, a "full" jar, and a "basic" jar. The basic jar would have > > about 8 classes, being about 4 classes of core functionality and 4 basic > > Rule classes. In this form I think the "basic" jar could be entirely > > appropriate for use by projects such as an i18n library without > > resorting to creating a new project. Xmlio by itself doesn't provide any > > functionality to actually instantiate objects or set properties; you > > need to write one or more subclasses of SimpleImportHandler (similar to > > ContentHandler), so by the time that is done I think that code based on > > Digester and xmlio would be pretty similar in size. > > > > There is one other significant issue: required libraries. Digester > > depends upon BeanUtils, mainly because it performs dynamic conversion > > between strings and other datatypes such as int, bool, etc. For a > > light-weight parsing library this could be a nuisance; I expect we could > > find a way of making automatic datatype conversion (and therefore > > BeanUtils functionality) optional though. Digester also depends upon > > commons-logging. I did make a proposal a while ago to make logging > > dependencies in Digester optional; the patch wasn't received with any > > great enthusiasm at the time, but with people actually pushing for this > > it might make it into Digester2. > > I agree that the core/basic jar should not have any dependencies. > I look forward to find a way to bring these two together! > > > > > > > > > > > Regarding the "out" part of the xmlio libs: this is basically a > > collection of static functions doing simple but useful xml string > > encoding etc., and a stream class that does auto-indenting. Digester > > certainly doesn't have anything like this. This code does feel like it > > might be at home in "lang" or "codec"... > > > > > > > > Oliver, if there was a "digester2" project which provided a "basic" jar > > that was pretty light-weight and had only optional dependencies on > > commons-beanutils and on commons-logging, might you consider using that > > in i18n (or even Slide) instead of the xmlio code? (And would you be > > interested in helping to create digester2??). > > > > I'm finally going to be free of the horror that is my current job in > > December, and plan to spend a fair chunk of January getting a Digester2 > > up and running (assuming that Craig/Robert et al are happy with that). > > Even if xmlio goes ahead, and the i18n component uses it I will still > > keep its features in mind when working on Digester2. > > > > Cheers, > > > > Simon > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
