On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote: > > 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. > > You mean stringify the child elements too, like XSLT does if you ask for > the text of a mixed-content element?
Yes. > I suppose we could do this, though I am not entirely sure how much use > this would be. Can you think of a use-case? Think of the transformation of our web pages. There is structure information wrapping pure XHTML. You would not want a callback for all formatting tags, would you? Maybe this is not a very common use of Digester, though... > If you mean pass a DOM tree into the Action to represent the "full body" > content, I think not :-). Certainly not. I think there is no place for the DOM in Digester. > > > Or are you by chance referring to my suggestions for xml-rules? > > > > No, what are they? > > I was puzzled about your reference to "reflection" in the previous > email, as accessing Rule (now Action) classes is never done via > reflection. However in the RELEASE-NOTES.txt I do discuss possible > updates to the classes in the xmlrules package to use reflection to make > Action classes accessable via the xmlrules mapping file rather than have > the xmlrules java code contain an explicit mapping class for each Action > as is currently done. Is that so? I have no internal knowlede of beanutils, but I thought there is no other way of calling a parameterized method than by refelection methods. But I am happy to learn something here :) > > > > > > > > > > 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. > > That would be very cool. > > I remember the main issue being that Digester is built around the > concept of having patterns control what operations were executed for > each xml element, and having the invoked logic partitioned into many > small Rule classes. > > You wished the user to write a big switch statement in Java to determine > what operations were executed, as you felt that this was more natural to > people used to writing SAX code by hand. > > We did briefly discuss ways of layering the code so that these were two > possible options the user could choose between, but I couldn't see then > how this would be possible. Thanks for reminding me of my reservations :) Now I remember! Especially when writing rahter simply import code I think it is much easier and obvious to have all the code at one position instead of having it distributed into many classes. However, this seems to be rather simple to accomplish. You just register a single action to be matched for all elements and then access the context to tell you the path of the current element. Maybe having a conveniece method to match paths to the current element directly. Wouldn't this work? Speed is another issue with xmlio, as it is really fast. But with some optimizations geared towards this, digester shoudn't relly be much slower anyway... > If you can think of some way of merging these quite different > approaches, I'm very keen to hear it. Or if you feel more kindly toward > a "distributed" pattern-matching + Action class approach, then that > would resolve the major issue and we can look at how the other xmlio > features could be provided in Digester (well, we can do that anyway!). Are you thinking of the export features? Thinking of the import features, having more than one actions being invoked on a certain element would be essantial. Just think of some sorf of logging or debugging action that is triggered with every element next to the normal processing. Does this currently work with digester 2? Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
