Re: [digester] initial code for Digester2.0
On Fri, 4 Feb 2005 08:57:05 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Isn't it about time to give Digester2 a place in SVN, so I can either create patches against it or directly commit to it. What about a branch in commons proper? Or at least the sandbox? Done. Do you have commit rights to Digester? If not, I'd be happy to propose a vote... Well, not quite sure, how this is handled, but as I have commit access to commons transaction, I should have rights on Digester as well. But I seem to remember that it is polite to have some sort of vote done by the current committers. Who are the current committers? Is there anyone other than you? Just checked it and I actually have commit access and have shamelessly added my name to the list of Digester2 developers. I hope that's ok for everyone, if not I will undo this ASAP. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Fri, 2005-02-04 at 08:57 +0100, Oliver Zeigermann wrote: On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Do you have commit rights to Digester? If not, I'd be happy to propose a vote... Well, not quite sure, how this is handled, but as I have commit access to commons transaction, I should have rights on Digester as well. Ah yes .. I forgot that karma for commons covers all projects.. But I seem to remember that it is polite to have some sort of vote done by the current committers. Yes. Who are the current committers? Is there anyone other than you? Robert Donkin also keeps an eye on Digester, though he's been more involved in Betwixt than Digester recently. Craig McC certainly qualifies as a committer, but appears to be kept busy by other projects. Otherwise, it's just me. Digester2 is just me so far, though. I'm happy for you to commit to the digester2 directory, and don't think there is anyone else you need to ask. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Fri, 04 Feb 2005 21:19:46 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Digester2 is just me so far, though. I'm happy for you to commit to the digester2 directory, and don't think there is anyone else you need to ask. Cool. I will need to do some work for money the next two weeks, but will contribute the promised stuff ASAP. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
As you've discovered, at the technical level Commons karma is project-wide. Socially, the practice has been to do exactly what you've done -- ask to participate and get accepted by the other developers working on that package. +1 on Oliver for Digester. I wish I had time to participate -- the ideas sound really interesting -- but it's good to see that the package is being cared for so ably. Craig On Fri, 4 Feb 2005 09:21:44 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Fri, 04 Feb 2005 21:19:46 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Digester2 is just me so far, though. I'm happy for you to commit to the digester2 directory, and don't think there is anyone else you need to ask. Cool. I will need to do some work for money the next two weeks, but will contribute the promised stuff ASAP. Oliver - 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]
Re: [digester] initial code for Digester2.0
Not sure if it's been discussed already, but I'm very much in favor of this (from the Wiki): - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
(oops, wrong button) Not sure if it's been discussed already, but I'm very much in favor of this (from the Wiki): ' It would be nice for SetProperties and SetNestedProperties rules to automatically map xml attributes and element names like foo-bar to bean properties of form fooBar. ' It's actually listed as a possible enhancement for 1.7, but wherever it ends up, it will be appreciated. (Assuming it isn't there already and I missed it...) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Fri, 2005-02-04 at 10:45 -0700, Wendy Smoak wrote: (oops, wrong button) Not sure if it's been discussed already, but I'm very much in favor of this (from the Wiki): ' It would be nice for SetProperties and SetNestedProperties rules to automatically map xml attributes and element names like foo-bar to bean properties of form fooBar. ' It's actually listed as a possible enhancement for 1.7, but wherever it ends up, it will be appreciated. (Assuming it isn't there already and I missed it...) Thanks for the feedback Wendy. I added that to-do item, so I'm sure it will get added eventually :-). If you feel like having a go at this yourself, I would be very happy to see a patch. Otherwise, it is lower on my priority list than getting the basic digester2 structure sorted so may be quite a while away from being implemented. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
From: Simon Kitching [EMAIL PROTECTED] ' It would be nice for SetProperties and SetNestedProperties rules to automatically map xml attributes and element names like foo-bar to bean properties of form fooBar. ' If you feel like having a go at this yourself, I would be very happy to see a patch. Much as I'd love to play with Digester instead, homework wins out (for the moment at least.) Let's see how long it takes me to write a small recursive-descent parser that reads in arithmetic expressions, parses each one into an abstract syntax tree, and evaluates it. :) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Thu, 03 Feb 2005 15:38:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
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...
Ok, I see. It would be reasonably simple to implement; we already
calculate the full text for each element (so we can pass it to the body
methods) in the SAXHandler class; we just need to keep appending these
instead of discarding them when the element ends.
One issue, I guess, is that by the end of the document we have a
StringBuffer that contains the entire text for the entire document -
which might take up a bit of memory. So maybe we need some mechanism for
an Action to tell the SAXHandler [from its begin() method, via a mixin
interface, or otherwise] that it wants a full text tree. The SAXHandler
can then start accumulating.
If you wished to contribute such a patch, I think I'd be in favour of
it.
I agree and will contribute such a patch. I will think about such a
mechanism and will discuss it as soon as I have something.
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 :)
Just some minor misunderstanding I think..
The digester framework invokes Rule (Action) classes directly. There is
no reflection involved in the invocation of Rule (Action) classes.
I know. But I was thinking of ActionCallMethod having code like
Object result = MethodUtils.invokeMethod(
target, methodName,
paramValues, paramTypes);
Isn't that done by reflection?
I am proposing that xmlrules actually uses reflection to generate a set
of Action objects when parsing its rule configuration input file. Of
course the parsing of the actual user input would then be done in the
normal manner (with the digester framework calling the Actions
directly).
The Rule (Action) classes interact with domain-specific (user) classes
via BeanUtils and reflection. I don't see any alternative, except for
the pre-processor type xml mapping tools, or runtime bytecode
generation, neither of which are really Digester's domain.
Well, there it is, my reflection. So we had a misunderstanding. The
options you name are worse than refelection, I agree, but why using
the BeanUtils in the first place? Isn't plain refelction sufficient?
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?
Hmm.. If we had a class that implements RuleManager that always returns
a custom Action no matter what the path, then all events would be
forwarded to the user-provided action, where the user can call
context.getMatchPath()
to access the current path, and determine from there what operations to
perform.
// xmlio-style digester
Action myHandler = new AbstractAction() {
public void begin(
Context context,
String namespace, String name,
Attributes attrs) {
String path = context.getMatchPath();
if
Re: [digester] initial code for Digester2.0
Hi Oliver, I look forward to seeing your ideas on stringifying trees of elements. The Rule (Action) classes interact with domain-specific (user) classes via BeanUtils and reflection. I don't see any alternative, except for the pre-processor type xml mapping tools, or runtime bytecode generation, neither of which are really Digester's domain. Well, there it is, my reflection. So we had a misunderstanding. The options you name are worse than refelection, I agree, but why using the BeanUtils in the first place? Isn't plain refelction sufficient? Well, I don't believe pre-processing is worse than digester; it can be a great solution in some situations. And for the rest, there's Digester :-) Digester uses BeanUtils to do type-conversion (via its ConvertUtils component), converting the strings extracted from the xml to whatever types the target methods take. BeanUtils also treats DynaBean classes as if they were normal Java classes, which is needed for at least one very important Digester user: struts. The reflection stuff we use from BeanUtils is only a few dozen lines so I guess we could import that into Digester itself. However the ConvertUtils stuff has a lot of code for typeconversion that I would be reluctant to duplicate. Maybe it's worth having a look at the new morph project as an alternative; it's more tightly focussed on typeconversion than BeanUtils. Hmm.. If we had a class that implements RuleManager that always returns a custom Action no matter what the path, then all events would be forwarded to the user-provided action, where the user can call context.getMatchPath() to access the current path, and determine from there what operations to perform. [snip] Thoughts? Looks good. However, we would need code that does the same as the default rule manager in getMatchingActions to match relative paths as well. xmlio uses the same path syntax as digester2 anyway. I will provide something for this as well. Excellent! I've not thought too much about obj-xml, and anyway Betwixt has that reasonably well covered as far as I know. The xmlio out part is much less than obj-xml, but rather a set of helpers on a low level. It also addresses byte encodings which has not been thought of in many XML printing solutions. Hmm.. not sure what to do with this code, then. But I'm pretty sure Digester is not the right home for it... If you mean having some debug Action that is triggered *for every element seen* in addition to the ones whose patterns actually match, then that can be done fairly easily by subclassing a Rules (in digester1.x) or RuleManager (in digester2.x) class. I guess we could build it in to the default class though... This would fit into the xmlio matching above: have an action that is called unconditionally. This could be useful in many scenarios. Shouldn't this be part of the default rule manager? There are usecases for having a set of actions that is returned if no pattern is matched. In particular, it is nice to be able to generate an error, unrecognised element, if you are very fussy about the input. I would definitely like to add this to DefaultRuleManager. And this feature would fit the xmlio scenario fine. Having a set of actions that are returned *in addition to* any others is possibly more controversial. There was someone looking for exactly that on the digester user list a while ago, wanting to execute SetNestedPropertiesRule for each element. I'm not so convinced this is a good idea, though: seems awful easy to shoot yourself in the foot! Apart from the debugging scenario you mention, I can't see a usecase for having an action that is returned *in addition to the other matching actions*. And I generally do debugging by enabling commons-logging output rather than write custom debugging actions anyway. Can you think of some usecases where this would be useful? Note also that currently RuleManager can return prebuilt lists when match is called; no List object needs instantiating. However if always present actions have to be inserted into each list, then a new List object is required to be created for each match call. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote: Of course if someone can demonstrate that non-namespace-aware parsers *are* still useful then I'll change my mind. Just to clarify, since I was being sloppy before (I gotta stop typing in shorthand) there is an important distinction: a) having NS-aware parser, always using NS-aware API methods b) having NS-aware parser, selectively using NS-aware API methods c) having non-NS-aware parser (and obviously never using NS-aware API methods) d) having NS-aware parser where the developer fixes a grammar that ignores any NS distinctions Even for Sax the performance difference between (a) and (b) is roughly a factor of 2 across all parsers when processing small (typical message-sized) docs that don't use NS. Mucking with (d) is supposed to result in significant wins when you tune the grammar handling to your app, but I haven't tried it myself and I've never seen timing differences quoted. I'm not trying to advocate any approach except to notice that, since your README mentioned requiring a namespace-aware parser, it sounded like there was a potential for options (b), (c), and (d) to become unintentionally closed to developers in Digester2 when they weren't in Digester1. I agree that old parsers providing (c) aren't particularly interesting, but if you spend any time tracing through the guts of the parsing, particularly when you see how DTDs are loaded for entity resolution, you begin to see (d) as having potential. Throwing (b) away may result in less code in Digester2, but it may be worth doing some timing tests to see if that code reduction is consequence-free. I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. Actually the XML spec distinguishes between the default namespace and all other namespaces, so parsers can reasonably make the same distinction and try to avoid a bunch of per-entity operations and temporary object creations in the case where there is no namespace. Look at the piccolo stats published on Sourceforge. Compare Soap, Soap+NS, and random XML-no NS timings and it suggests that NS ain't free. Useful links: Jade (now part of Javolution) http://javolution.org/api/index.html, look at the javolution.xml package (trades String for CharSequence to increase performance, but keeps NS) Picollo you probably already have the link for, but for anybody else interested: http://piccolo.sourceforge.net Zapthink comments on XML parsing challenges, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci85,00.html Developerworks articles on XML performance, http://www-106.ibm.com/developerworks/xml/library/x-perfap1.html Sun articles on XML performance, http://java.sun.com/developer/technicalArticles/xml/JavaTechandXML_part3/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Hi Simon! On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote: I look forward to seeing your ideas on stringifying trees of elements. Isn't it about time to give Digester2 a place in SVN, so I can either create patches against it or directly commit to it. What about a branch in commons proper? Or at least the sandbox? I've not thought too much about obj-xml, and anyway Betwixt has that reasonably well covered as far as I know. The xmlio out part is much less than obj-xml, but rather a set of helpers on a low level. It also addresses byte encodings which has not been thought of in many XML printing solutions. Hmm.. not sure what to do with this code, then. But I'm pretty sure Digester is not the right home for it... Agreed. Maybe a commons component of its own? Very small code, but reasonable in scope. Many people need XML printing Thoughts? If you mean having some debug Action that is triggered *for every element seen* in addition to the ones whose patterns actually match, then that can be done fairly easily by subclassing a Rules (in digester1.x) or RuleManager (in digester2.x) class. I guess we could build it in to the default class though... This would fit into the xmlio matching above: have an action that is called unconditionally. This could be useful in many scenarios. Shouldn't this be part of the default rule manager? There are usecases for having a set of actions that is returned if no pattern is matched. In particular, it is nice to be able to generate an error, unrecognised element, if you are very fussy about the input. I would definitely like to add this to DefaultRuleManager. And this feature would fit the xmlio scenario fine. Agreed. Having a set of actions that are returned *in addition to* any others is possibly more controversial. There was someone looking for exactly that on the digester user list a while ago, wanting to execute SetNestedPropertiesRule for each element. I'm not so convinced this is a good idea, though: seems awful easy to shoot yourself in the foot! Apart from the debugging scenario you mention, I can't see a usecase for having an action that is returned *in addition to the other matching When you populte beans or call methods on classes I would agree it rather is a hazard. But if you think of an XML document as some sort of message why shouldn't be there more than one part of a complex system that is interested in it? I need to think this over. Maybe it is time to do some coding and experiments now actions*. And I generally do debugging by enabling commons-logging output rather than write custom debugging actions anyway. Can you think of some usecases where this would be useful? Hmmm, using SAX it always is a bit tricky to get a good idea how your XML document that is being parsed *really* looks like. commons-logging is no good in that case. If you have something that collects the whole document and regenerates it this can be a very valuable debug information. Consider the stuff you parse is not in your file system, but comes from a stream from a remote server it isn't all obvious what is looks like. Note also that currently RuleManager can return prebuilt lists when match is called; no List object needs instantiating. However if always present actions have to be inserted into each list, then a new List object is required to be created for each match call. I understand what you say, but do not understand why a new list would have to be build with each match call. Why can't you statically addd the always present action into the list? Coul you explain? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Thu, 2005-02-03 at 23:36 +0100, Oliver Zeigermann wrote: Hi Simon! On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote: I look forward to seeing your ideas on stringifying trees of elements. Isn't it about time to give Digester2 a place in SVN, so I can either create patches against it or directly commit to it. What about a branch in commons proper? Or at least the sandbox? Done. Do you have commit rights to Digester? If not, I'd be happy to propose a vote... actions*. And I generally do debugging by enabling commons-logging output rather than write custom debugging actions anyway. Can you think of some usecases where this would be useful? Hmmm, using SAX it always is a bit tricky to get a good idea how your XML document that is being parsed *really* looks like. commons-logging is no good in that case. If you have something that collects the whole document and regenerates it this can be a very valuable debug information. Consider the stuff you parse is not in your file system, but comes from a stream from a remote server it isn't all obvious what is looks like. Good point. Note also that currently RuleManager can return prebuilt lists when match is called; no List object needs instantiating. However if always present actions have to be inserted into each list, then a new List object is required to be created for each match call. I understand what you say, but do not understand why a new list would have to be build with each match call. Why can't you statically addd the always present action into the list? Coul you explain? Possible, I guess. Just a bit tricky... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Isn't it about time to give Digester2 a place in SVN, so I can either create patches against it or directly commit to it. What about a branch in commons proper? Or at least the sandbox? Done. Do you have commit rights to Digester? If not, I'd be happy to propose a vote... Well, not quite sure, how this is handled, but as I have commit access to commons transaction, I should have rights on Digester as well. But I seem to remember that it is polite to have some sort of vote done by the current committers. Who are the current committers? Is there anyone other than you? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote:
- Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have written. As long as we can
provide a suitable default implementation in the Action
abstract class,
everything runs smoothly.
One example is the bodySegment callback that is now in Action. In
Digester 1.x we could not have added this to Rule without breaking all
custom Rule classes. But if digester2.0 had been released
without it, we
could have added it later with no source or binary compatibility
problems.
Of course because of Java's single-inheritance policy, it would be
impossible for a class to extend both Action and some other class. But
(a) this is extremely unlikely, and (b) using an adapter class works
around this anyway if it absolutely has to be done.
I prefer interface + default abstract implementation, the way Swing provides
e.g. Action* and AbstractAction. That way a class can still implement the
interface even if it extends from something else, and use a delegate to
implement the interface. You can still evolve the interface without
breaking existing classes that extend the abstract class. Of course, there
is nothing to force people to extend the abstract class, but you can make
it clear in the doco for the interface that not to extend the abstract
class is an explicit design choice that may have dire consequences.
Interesting.
Extending an interface by adding methods causes source and binary
incompatibility with all
*implementers* of the interface, but not with *users* of the interface.
So it is not a problem if classes like SAXHandler reference Action; user
subclasses
will still work fine with the new interface [1].
[1] Though if they override methods that have been modified in SAXHandler to
*use* the
new methods, then things might get hairy...
My major concern is that if we are going to warn people not to implement the
Action interface,
then what really is the point of providing it in the first place? As I said
above, I just cannot
think of any situation where a class would want to be an Action *and* extend
some other class.
Nevertheless, there are definite benefits to following a standard
convention...
I am +1 for using an interface and the default (why abstract?)
implementation like with Swing or SAX. Adding new (non-abstract) call
back methods later is restricted to additional ones onyway. You can
not replace methods or their semantics. Because of this you could
easily later (after 2.0) add something like
interface ExtendedAction extends Action {
... bodySegment(...);
}
class DefaultAction implements ExtendedAction {... }
which used to be
class DefaultAction implements Action {... }
and no existing code would break, but people would be free to use the
new, extended version.
I do not agree with people being asked to extend the default
implementation only as this would make the interface obsolete. But
with the stuff I tried to sketch above it should not be possible.
Hope this makes my point clear,
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
One section of the release notes says: The Digester now *always* uses a namespace-aware xml parser. I was wondering why this is. There are a lot of XML parsers out there, and some of them have done things like trade namespace awareness for performance. If somebody has a application where namespaces aren't an issue, why should they be limited to only using a namespace-aware parser? Not something that seems like an important issue if you are just using a Digester to process some kind of app config file, but is an issue if processing streams of XML data is fundamentally what the app is about. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote: My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. I am +1 for using an interface and the default (why abstract?) implementation like with Swing or SAX. I don't get why we would ever warn people not to implement the interface, beyond including JavaDoc that clarified what the behaviour contract is for the various methods. Part of a developer's job is to exercise judgement about what they are or are not going to do in their implementation. If the existing Action implementations and base class provides what a developer needs to do 99% of the time, they won't bother implementing the interface, but when they encounter that 1% scenario, its nice not to hit a brick wall. Here is a concrete example of why you could want to implement the interface and extend another class, I've actually had situations with the existing Digester where I'd wished I could do that. The one that I can recall now was an instrumentation issue. Doing debugging and performance tuning of a suite of rules can be tedious because, currently, the only options are either to watch a spew of logging messages or single-step your way through all the callbacks in a debugger (PAIN). If the major coupling points in the Digester had been abstracted by interfaces, it would have been easier to insert instrumentation proxies or EasyMock'd test implementations of classes at key points. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
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]
Re: [digester] initial code for Digester2.0
Hi Oliver,
On Wed, 2005-02-02 at 15:22 +0100, Oliver Zeigermann wrote:
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?
Well, I would prefer to avoid having users do:
addRule(new Pattern(/foo/bar), )
as this is just more readable:
addRule(/foo/bar, ...)
However if we ever do find that there are some patterns that just can't
be represented nicely as a string, then we could simply add a new
method:
addRule(Pattern p, ...) { }
and reimplement addRule to preserve compatibility:
addRule(String s, ... ) { addRule(new Pattern(s), ...); }
So in short, I would prefer [1] to keep the current String pattern as
one of the options, for user convenience, but I don't see any major
issue with adding Patterns later if we need them. I guess it would break
custom subclasses of RuleManager, but that would be a very rare thing to
do.
And right now, DefaultRuleManager definitely needs its patterns to be
strings, so if we had a Pattern class as the pattern, we would be
forcing users to create an instance just so the DefaultRuleManager could
turn it back into a string.
- I like the bodySegment vs. body design :)
Cool. Now I just have to implement it :-)
Ooops, doesn't it work, yet?
Minor detail. I just need to merge the code from the example I
referenced into the core. Why are there never enough hours in a day?
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.
You mean stringify the child elements too, like XSLT does if you ask for
the text of a mixed-content element?
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?
If you mean pass a DOM tree into the Action to represent the full body
content, I think not :-).
- 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.
Yes, I remember that thread. I'll re-read it.
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?
Suppose digester requires beanutils 1.7, but a user wants to call
digester from an app that is using beanutils 1.6 (or 1.8) or similar,
and the beanutils lib versions are incompatible.
In this situation, the user is currently out of luck (or at least there
is no documented solution).
But using classloaders it is possible to access classes different from
the classes available to other parts of an app. For example, webapps in
tomcat have their own private libs that are not available to either
tomcat or sibling webapps. Using this sort of trick, we could arrange
for digester to access all the beanutils classes via a user-provided
classloader, which accesses a beanutils-1.7.jar that is not in the
classpath for the rest of the app.
I haven't really thought about this in detail; it's just an idea at the
moment. I'm vaguely envisaging a method
Digester.setLibraryClassLoader(ClassLoader cl)
or
Digester.setLibraryClasspath(String customClasspath)
It might end up better to load the whole of Digester in a custom
classloader, in which case the problem is pushed back up to the user
domain; all we would need to do is document how to do this rather than
actually add any custom code.
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.
Well, it's done. I hope to post the new version later today.
RE: [digester] initial code for Digester2.0
My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. Maybe I wasn't clear enough - I didn't say that the Action interface should not be implemented by anything except the default implementation (what indeed would be the point of that?). The point is, the majority of Actions that people create would extend the default implementation, and would be (mostly) immune to API evolution. People who decide to implement Action directly are free to do so - and they accept that if they do so then they will need to evolve with the API. As Oliver said, if you use an interface then you have some extra options for how you add functionality, such as adding new interfaces that extend Action. Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote: --- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote: My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. I am +1 for using an interface and the default (why abstract?) implementation like with Swing or SAX. I don't get why we would ever warn people not to implement the interface We (digester developers) want the ability to add methods to Action in minor releases. But adding methods to an interface breaks all classes that directly implement that interface. So people should not extend an Action interface because their classes could be broken by a minor-version update of Digester, eg 2.0 - 2.1. They wouldn't be forbidden from implementing Action, just warned about the consequences. By encouraging users to extend AbstractAction instead of implementing Action, we have the chance to provide default implementations for new functionality, and thereby give ourselves the chance to improve digester in minor releases without breaking user code. Here is a concrete example of why you could want to implement the interface and extend another class, I've actually had situations with the existing Digester where I'd wished I could do that. The one that I can recall now was an instrumentation issue. Doing debugging and performance tuning of a suite of rules can be tedious because, currently, the only options are either to watch a spew of logging messages or single-step your way through all the callbacks in a debugger (PAIN). If the major coupling points in the Digester had been abstracted by interfaces, it would have been easier to insert instrumentation proxies or EasyMock'd test implementations of classes at key points. I don't know much about EasyMock, and have only rarely used java.lang.reflect.Proxy. But if having an Interface rather than an abstract class makes it easier to use these, then that's a very good point in favour of Colin Sharples' recommendation to create Action (interface) + AbstractAction (class). Normal code extends AbstractAction, but instrumentation code can proxy the interface if it really needs to. And as these uses of the interface are transient, we don't have to worry about breaking code when the interface is modified, right? Does this satisfy your concerns? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
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]
Re: [digester] initial code for Digester2.0
On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
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...
Ok, I see. It would be reasonably simple to implement; we already
calculate the full text for each element (so we can pass it to the body
methods) in the SAXHandler class; we just need to keep appending these
instead of discarding them when the element ends.
One issue, I guess, is that by the end of the document we have a
StringBuffer that contains the entire text for the entire document -
which might take up a bit of memory. So maybe we need some mechanism for
an Action to tell the SAXHandler [from its begin() method, via a mixin
interface, or otherwise] that it wants a full text tree. The SAXHandler
can then start accumulating.
If you wished to contribute such a patch, I think I'd be in favour of
it.
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.
Phew! :-)
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 :)
Just some minor misunderstanding I think..
The digester framework invokes Rule (Action) classes directly. There is
no reflection involved in the invocation of Rule (Action) classes.
I am proposing that xmlrules actually uses reflection to generate a set
of Action objects when parsing its rule configuration input file. Of
course the parsing of the actual user input would then be done in the
normal manner (with the digester framework calling the Actions
directly).
The Rule (Action) classes interact with domain-specific (user) classes
via BeanUtils and reflection. I don't see any alternative, except for
the pre-processor type xml mapping tools, or runtime bytecode
generation, neither of which are really Digester's domain.
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?
Hmm.. If we had a class that implements RuleManager that always returns
a custom Action no matter what the path, then all events would be
forwarded to the user-provided action, where the user can call
context.getMatchPath()
to access the current path, and determine from there what operations to
perform.
// xmlio-style digester
Action myHandler = new AbstractAction() {
public void begin(
Context context,
String namespace, String name,
Attributes attrs) {
String path = context.getMatchPath();
if (path.equals(..)) {
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 05:48 -0800, Reid Pinchback wrote: One section of the release notes says: The Digester now *always* uses a namespace-aware xml parser. I was wondering why this is. There are a lot of XML parsers out there, and some of them have done things like trade namespace awareness for performance. If somebody has a application where namespaces aren't an issue, why should they be limited to only using a namespace-aware parser? Not something that seems like an important issue if you are just using a Digester to process some kind of app config file, but is an issue if processing streams of XML data is fundamentally what the app is about. Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Removing code that handles non-namespace parsers from digester simplifies the code and reduces the library size. It also pushes users to write their code correctly; code that processes XML and doesn't handle namespaces is fundamentally broken and we shouldn't be providing tools that encourage people to write broken code. However if you can give an example of a modern and maintained xml parser that deliberately doesn't support namespaces in order to improve performance or reduce footprint, I will gladly reconsider. Or of course the consensus here favours supporting broken parsers :-) Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Wow, that is an unexpectedly harsh reaction. My reason for asking was simple, and I believe not unreasonable. You were the one asking for feedback on your proposal. Using the namespace-based API of an XML parser is known throughput substantially, covered in a host of Java xml mag articles, available from google searches, and one or two of the Java performance tuning books still in distribution. XML performance tuning is a tough area, and people continually struggle with it. I don't recall the SAX-only stats, but I know that for DOM parsers you can shoot for an increase XML processing bandwidth by an order of magnitude through a change in parser and not using NS. Antiqueness of parsers isn't the issue. I think it helps to keep in mind that NS was intended as a way of creating name-resolution scopes that allow the merging of document structures from different origins that otherwise could experience element and attribute name clashes. When somebody has an application that doesn't require that kind of merging, and they aren't using a namespace-dependent XML technology like Soap or XMLSchma, then using using NS features of an NS parser can be a burden without corresponding benefit. Under the hood, that parser has to do a lot of work to continually manage the NS resolution of the node names. It has no way of knowing that the work is pointless - you've told it to assume that there is a point when you use the NS features. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote: --- Simon Kitching [EMAIL PROTECTED] wrote: Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Wow, that is an unexpectedly harsh reaction. My reason for asking was simple, and I believe not unreasonable. You were the one asking for feedback on your proposal. Sorry, Reid. I didn't mean it that way. I apologise for any offense. I was just stating my personal opinion - that every app eventually drops support for obsolete technologies, and I think it's time to drop support for non-namespace-aware parsers. I was serious, too, about users of old technology sticking with digester 1.x. I'm aware that upgrading core libs can sometimes be a pain, but digester1.x is still there and isn't going away (I'm one of the maintainers for that code, and have every intention of continuing that even when 2.0 is out). I just don't see the point of migrating the backwards compatibility code from the 1.x series. Of course if someone can demonstrate that non-namespace-aware parsers *are* still useful then I'll change my mind. Using the namespace-based API of an XML parser is known throughput substantially, covered in a host of Java xml mag articles, available from google searches, and one or two of the Java performance tuning books still in distribution. XML performance tuning is a tough area, and people continually struggle with it. I don't recall the SAX-only stats, but I know that for DOM parsers you can shoot for an increase XML processing bandwidth by an order of magnitude through a change in parser and not using NS. Antiqueness of parsers isn't the issue. Is there any chance you could provide a reference to such an article? I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. Surely that's a fraction of a percent of the parser performance, memory usage, and processing time. So why wouldn't a parser do it? Leaving out *validation* would improve performance and footprint significantly, but validation and namespace support are unrelated. I had a quick look for high-performance/small-footprint xml parsers: parser NS-support maintained? Piccolo y y Aelfred y y ElectrixXML y n? (can't find a current website) MinML n n (last release nov 2001) NanoXML y n (last release april 2002) JapiSoft y y (commercial) I also googled for xml parser performance namespace but didn't get anything relevant. I think it helps to keep in mind that NS was intended as a way of creating name-resolution scopes that allow the merging of document structures from different origins that otherwise could experience element and attribute name clashes. When somebody has an application that doesn't require that kind of merging, and they aren't using a namespace-dependent XML technology like Soap or XMLSchma, then using using NS features of an NS parser can be a burden without corresponding benefit. Under the hood, that parser has to do a lot of work to continually manage the NS resolution of the node names. It has no way of knowing that the work is pointless - you've told it to assume that there is a point when you use the NS features. True. Namespaces are not relevant in many contexts. But as noted above, I do find it hard to believe that parser has to do a lot of work to manage NS resolution. If you can show me I'm wrong, I'll buy you a beer ;-) Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Simon Kitching wrote: BTW, should we contact the car companies, and tell them their customers prefer suffixes? Focus Ford Mustang Ford Thunderbird Ford (I'm mostly kidding...) I think the analogy is incomplete, you forgot the objet being qualified by the brand. Would you say Car Ford Focus Car Ford Mustang Car Ford Thunderbird rd or Ford Focus Car Ford Mustang Car Ford Thunderbird Car ? :) Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: Does this mean you prefer Action to Rule? I certainly expect to hear from people who want to keep the current names... I'm not wedded to Rule but I do have a concern about Action. I suspect it could make Struts code rather confusing. __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. I vote for prefixes. That sounds reasonable. However I do dislike having mutual dependencies between java packages; a DAG (directed acyclic graph) is good for a number of reasons. I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Reid Pinchback wrote: I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. Can you give an example of a difficult refactoring due to a cyclic dependency between 2 packages ? I'm not sure to understand the practical issue. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Simon Kitching wrote: Does this mean you prefer Action to Rule? I certainly expect to hear from people who want to keep the current names... No preference there, [and I'll get used to prefix/suffix, whichever way it goes, it's not THAT big of a deal, but you asked...] -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Sure thing. Just to make it easier to envision, let's get
packages out of the equation. Just think about cyclic
dependencies between two classes in the same package.
That is enough to show the problem; packages just add complexity
because the dependencies can be much harder to detect visually
(usually you would use something like JDepend to spot them)
and harder to unwind.
Refactoring is harder simply because you have to do a larger
number of smaller steps. Doesn't mean impossible, more steps
just mean more work, more time, more money. Tricky enough when
only two classes are involved, harder as the number of classes
involved in the cycle increase. Get enough classes involved,
and you start to hear statements like it will be easier to
throw that away and start over again than it will be to fix it.
class A {
int a;
int fooA(int arg) {
// 1a. do stuff with {B.fooB,a,arg}
// 2a. do other stuff with result and {a}
}
}
class B {
int b1, b2;
int fooB(int arg) {
// 1b. do stuff with {A.fooA,b1,arg}
// 2b. do other stuff with result and b2
// 3b. do stuff with {A.fooA,b2,arg}
}
}
Refactoring remains possible, but tricky because
you have both compile-time code dependencies and
run-time state dependencies. You are faced with
things like factoring out small fragments of code
into helper classes, and maybe introducing an
interface to at least eliminate the compile-time
dependency between A and B, even if the run-time
dependency remains.
Often the solution ends up something like
a) make interface I
b) create class C implements I
and migrate some of A and B state into C
c) modify A and B to share I
It works, it just takes time... and often you
are doing it before even trying to tackle whatever
bug or feature enhancement you were faced with
in the first place.
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
I very much like that and think it really is straight forward. Comments: - Why is Action an abstract class? - Wouldn't it be possible (and even desirable) to have a more general Pattern class instead of a String in Digester#addRule? - I like the bodySegment vs. body design :) - I like the no dependency and digester2 package approach - It's no secret that I am no fun of reflection stuff: is it really necessary to have the subclasses of Action be part of the *very*, *very* digester *core*? 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. Oliver On Mon, 31 Jan 2005 23:09:28 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi, As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Comments from all commons-dev subscribers are welcome, but particularly from Craig and Robert. The RELEASE-NOTES.txt file gives a brief overview of what I've done so far, and what I personally would like to see. This is *not* intended to be final code, but rather to solicit yes/no feedback on what people like/dislike about the posted code. As you will see, many parts are still missing and I personally would still like to see significant changes even to parts already included (see RELEASE-NOTES.txt). However the basic structure is there, including a number of controversial (I expect) name changes. Once we get the general opinions out, and I have massaged the code into something that meets general concensus I hope to then add it to the sandbox for everyone to hack away at. 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]
Re: [digester] initial code for Digester2.0
On 2005-01-31 9:59:52, Simon Kitching wrote: As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Simon, Joran classes and documentation mention that it is influenced by Digester. Is your design for Digester 2.0 influenced by Joran? If it is, this should be mentioned as a matter courtesy. Regards, -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Tue, 2005-02-01 at 20:40 +0100, Ceki Gülcü wrote: On 2005-01-31 9:59:52, Simon Kitching wrote: As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Simon, Joran classes and documentation mention that it is influenced by Digester. Is your design for Digester 2.0 influenced by Joran? If it is, this should be mentioned as a matter courtesy. Hi Ceki, The only influence so far is the use of the word Action instead of Rule. I gave credit to Joran for this influence in my email to the dev list, but don't think a single name is quite enough to earn credit in the documentation. And anyway, I'm still waiting to see if people are happy changing name Rule - Action. I did read the Joran code about 12 months ago. I should take time to look back at Joran again to see if there are any ideas that are suitable for borrowing for digester 2.0; if this does happen I promise I will give due credit. If you are aware of anything that might be of use to Digester, then it would be great if you could point it out... Regards, Simon PS: How's the skiing this season? That's something I really miss after leaving Switzerland... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Hi Oliver, On Tue, 2005-02-01 at 18:04 +0100, Oliver Zeigermann wrote: I very much like that and think it really is straight forward. Comments: - Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. - 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? - I like the bodySegment vs. body design :) Cool. Now I just have to implement it :-) 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 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. (2) that upgrading an application using digester 1.x to digester2.x requires changes to all the import statements. 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. - It's no secret that I am no fun of reflection stuff: is it really necessary to have the subclasses of Action be part of the *very*, *very* digester *core*? Sorry, I don't follow this. Could you explain? One thing the proposed code does do is separate ActionFactory from Digester, so the Digester class doesn't have compile-time dependencies on any Action subclasses. 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. Or are you by chance referring to my suggestions for xml-rules? 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? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] initial code for Digester2.0
- Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. I prefer interface + default abstract implementation, the way Swing provides e.g. Action* and AbstractAction. That way a class can still implement the interface even if it extends from something else, and use a delegate to implement the interface. You can still evolve the interface without breaking existing classes that extend the abstract class. Of course, there is nothing to force people to extend the abstract class, but you can make it clear in the doco for the interface that not to extend the abstract class is an explicit design choice that may have dire consequences. * yes, the name Action is quite overused. Not that I can think of a better alternative... ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote: - Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. I prefer interface + default abstract implementation, the way Swing provides e.g. Action* and AbstractAction. That way a class can still implement the interface even if it extends from something else, and use a delegate to implement the interface. You can still evolve the interface without breaking existing classes that extend the abstract class. Of course, there is nothing to force people to extend the abstract class, but you can make it clear in the doco for the interface that not to extend the abstract class is an explicit design choice that may have dire consequences. Interesting. Extending an interface by adding methods causes source and binary incompatibility with all *implementers* of the interface, but not with *users* of the interface. So it is not a problem if classes like SAXHandler reference Action; user subclasses will still work fine with the new interface [1]. [1] Though if they override methods that have been modified in SAXHandler to *use* the new methods, then things might get hairy... My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. Nevertheless, there are definite benefits to following a standard convention... * yes, the name Action is quite overused. Not that I can think of a better alternative... ;-) Yep :-( Rule is at least different - but unfortunately can be misleading. A tough choice.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Tue, 2005-02-01 at 16:20 +0100, Emmanuel Bourg wrote: Reid Pinchback wrote: I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. Can you give an example of a difficult refactoring due to a cyclic dependency between 2 packages ? I'm not sure to understand the practical issue. Well, I don't know about the refactoring issues. But I prefer avoiding cyclic dependencies because: * You can learn the classes in packages in order, without bouncing back and forth between packages * javac, javadoc, UML diagramming tools, etc. can process code in directory order without having to bounce back and forth. This just has to improve performance and reliability. * you can trim down a distribution by progressively leaving out packages * when porting code or revising code (including refactoring) you can do this in a progressive manner, starting with the package at the root of the dependency tree and working forward rather than having to migrate classes scattered across a selection of packages. * having clean package dependencies encourages lower code coupling. Quite often I find it prompts me to create clean interfaces to break inter-package dependencies, and I then find those interfaces are sensible for many reasons. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
XXXRule -- ActionXXX for all XXX By using a prefix instead of a suffix, all the Action classes group nicely together in the javadoc. I tend to prefer the type as a suffix, to keep them grouped in the javadoc I would rather use an action(s) subpackage. With or without 's' is another debate ;) Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
hi simon my main development machine blew up last week and i'm still struggling to get up and running on a secondary one. i haven't had a chance to look at the code yet (and it might be a fair while before i do) but i'd like to suggest that (when the time comes) you consider developing in proper rather than the sandbox. subversion provides a number of options which weren't available in cvs. - robert On 31 Jan 2005, at 10:09, Simon Kitching wrote: Hi, As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Comments from all commons-dev subscribers are welcome, but particularly from Craig and Robert. The RELEASE-NOTES.txt file gives a brief overview of what I've done so far, and what I personally would like to see. This is *not* intended to be final code, but rather to solicit yes/no feedback on what people like/dislike about the posted code. As you will see, many parts are still missing and I personally would still like to see significant changes even to parts already included (see RELEASE-NOTES.txt). However the basic structure is there, including a number of controversial (I expect) name changes. Once we get the general opinions out, and I have massaged the code into something that meets general concensus I hope to then add it to the sandbox for everyone to hack away at. 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]
Re: [digester] initial code for Digester2.0
On Mon, 2005-01-31 at 22:20 +, robert burrell donkin wrote: hi simon my main development machine blew up last week and i'm still struggling to get up and running on a secondary one. i haven't had a chance to look at the code yet (and it might be a fair while before i do) but i'd like to suggest that (when the time comes) you consider developing in proper rather than the sandbox. subversion provides a number of options which weren't available in cvs. No hurry on having a look at the code. However I have posted javadoc for the new code here: http://www.apache.org/~skitching/digester2-javadoc/api/index.html So while you're waiting for your new machine, you've now got something to do Robert :-) Re developing digester2 in proper: well, it really depends upon whether there is consensus on the ideas I am putting forward. If people are unsure, and want to see a more complete framework before saying yea/nay then sandbox might be more appropriate. If we all agree on the basics, then proper would be fine. But yes, it's so much easier to manage branches with svn. Of course there's no problem either with using svn cp to copy from digester-proper into the sandbox, ie make the sandbox contain a branch of Digester, right? [go subversion!] Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Mon, 2005-01-31 at 11:23 +0100, Emmanuel Bourg wrote: XXXRule -- ActionXXX for all XXX By using a prefix instead of a suffix, all the Action classes group nicely together in the javadoc. I tend to prefer the type as a suffix, Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. to keep them grouped in the javadoc I would rather use an action(s) subpackage. With or without 's' is another debate ;) That sounds reasonable. However I do dislike having mutual dependencies between java packages; a DAG (directed acyclic graph) is good for a number of reasons. So if we have an o.a.c.d.actions package for the standard actions, then we probably need an o.a.c.d.factory package so the ActionFactory class (which now holds the old Digester.addXXXRule factory methods) can be pushed down into it. We would then have dependencies of: o.a.c.d.actions -- o.a.c.d o.a.c.d.factory -- o.a.c.d.actions, o.a.c.d which is acceptable. Thoughts? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
From: Simon Kitching [EMAIL PROTECTED] Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. Another vote for suffix - I prefer CallMethodAction to ActionCallMethod. Will ActionFactory have all of the available Action constructor signatures? Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote: From: Simon Kitching [EMAIL PROTECTED] Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. Another vote for suffix - I prefer CallMethodAction to ActionCallMethod. Ok. Does this mean you prefer Action to Rule? I certainly expect to hear from people who want to keep the current names... Will ActionFactory have all of the available Action constructor signatures? Yes. I just don't want to implement them all until the final names have been decided on... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote: From: Simon Kitching [EMAIL PROTECTED] Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. Another vote for suffix - I prefer CallMethodAction to ActionCallMethod. BTW, should we contact the car companies, and tell them their customers prefer suffixes? Focus Ford Mustang Ford Thunderbird Ford (I'm mostly kidding...) Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
