On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote: > > - Wouldn't it be possible (and even desirable) to have a more general > > Pattern class instead of a String in Digester#addRule? > Can you explain more?
Well, RuleManager is an abstract class (discussion abstract class vs. interface applies here as well) with a default implemenation, but Pattern is a String. Wouldn't it be more flexible with little extra cost to have a Pattern interface with a default String Path implementation like the current one? > > - I like the bodySegment vs. body design :) > Cool. Now I just have to implement it :-) Ooops, doesn't it work, yet? > > The inspiration can be found in the digester 1.6 > "src/examples/api/document-markup" example, where the code has to go to > great lengths to handle XHTML-style input. I was also wondering, there may be occasions where it is desirable to have the full body *including tags* passed in a call back. This would mostly apply in mixed context tags where text is mixed with style information that do not need processing like with XTHML. > > - I like the no dependency and digester2 package approach > > Ok. I really thought people wouldn't like "o.a.c.digester2". In fact, > I'm not sure I like it myself. The main reasons are: > (1) that I don't know any other projects that do this. Tomcat, struts, > commons-collections, etc, don't do this. Tomcat does not need to as it is no library. commons-collections should better have done this - for more details have a look at the thread all this was discussed in recently. > (2) that upgrading an application using digester 1.x to digester2.x > requires changes to all the import statements. I understand Digester2 is incompatible to 1.x anyway, so changes to the import statements aren't the primary problem, right? If it was fully compatible, there would be no need to call the package digester2 anyway. > As noted, there is still currently a dependency on BeanUtils; digester > uses too much from that package to copy the classes into digester. But > as noted I would like to experiment with accessing BeanUtils > functionality via a custom classloader so that if people have problems > with clashing lib versions there is a solution. Could you elaborate this? > I quite like Emmanuel Bourg's suggestion of an "actions" subpackage to > hold the subclasses of Action, which would show that they aren't tightly > coupled to the Digester "core" classes. That's exactly what I would want to see. > Or are you by chance referring to my suggestions for xml-rules? No, what are they? > > > > If so I would be more than happy to abandon xmlio (in) as - apart from > > philosophical considerations - it would be superfluous and I would > > offer development support for digester if that is welcome. > > You would be very welcome indeed to work on digester if you wish. > > My memory of our discussions about xmlio/digester is a little vague now, > but I remember coming to the conclusion that their concepts were > different in some fundamental ways. If we *can* find some way to merge > the two projects, though, I'm all for it. Does the fact that Digester > and SAXHandler have been split apart make this possible now? Honestly, I do not remember much of that discussion, but I thought we came to the conclusion that we would try to make xmlio obsolete with Digester2. The reason I preferred xmlio over digester was simplicity and obviousness mainly. Now this new Digester2 core (even better with the Action subclasses in a package of their own) is simple and obvious as well, so I see no strong reason to stick to xmlio. Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
