DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35096>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35096 ------- Additional Comments From [EMAIL PROTECTED] 2005-05-27 07:32 ------- Hi Rahul, Thanks very much for offering a patch for this. It is always good to see people offering solutions rather than just problems :-). I do have some concerns about this approach though, that mean I personally would prefer not to see this patch committed as-is. If you wished to work on it some more, I'd be happy to help. However CallMethodRule has acted this way since the very first release, so I don't see it being worthwhile to delay the next release to get this in. Of course others may see it differently; if any other digester committers are listening, please speak up! As I note below, a user rule should be able to do anything a built-in rule can. So if this problem is solvable, then it should be solvable via a bunch of new Rule classes that can be downloaded separate from the commons-digester release. That would be a good thing I think as people can use them and give feedback before the new functionality becomes part of the digester core. I think it quite feasable to put such "extras" code up on the apache site somewhere for people to download. The concept of a stack of arrays was, I think, rather ugly in the first place. Extending this by having a stack of lists of arrays isn't, in my opinion, the way to go. And while it really will be necessary to somehow link CallParamRule objects to their associated CallMethodRule I don't think using integer indexes are the solution. It just feels clumsy. Having any kind of rule treated "special" by the digester core is also undesirable. It is much nicer to have a core that just provides generic rule services, and then the rule classes are layered on top. Ok, apart from all those factory methods that are also on the Digester class. Having this layering means that a user rule can do anything that a built-in rule can. Currently this is true, and I'd like to see it stay that way. I was experimenting a while ago with the following: * having an interface (MethodInvoker or somesuch name) that the CallMethodRule implements. * having XXParamRule objects obtain the Rules object from the digester and iterate over the list of Rule objects until they find themself. The immediately preceding MethodInvoker rule object is then the one that they associate themself with. This can be done when setDigester is called, ie once only. * having the MethodInvoker interface define method setParameter(int i, Object value) that the various ParamRule objects could then call, rather than directly accessing a "parameter stack" data structure. * having each CallMethodRule (which implements MethodInvoker) manage its own stack of parameter data. This could still be a stack of arrays internally, but it is now a data structure private to the class, which is better than the current paramstack object which is exposed everywhere. The bit about XXParamRule classes scanning the list of rules to find the previous CallMethodRule means that code like this: digester.addCallMethod(....); // rule 1 digester.addCallParam(...); // automatically associates with rule 1 digester.addCallMethod(....); // rule 2 digester.addCallParam(...); // automatically associates with rule 2 works in an intuitive fashion. A CallParamRule associates with the most recently added CallMethodRule. None of this should need changes to the digester core as far as I can see; it can all be done as "user" rules, though of course that means duplicating or subclassing a number of rule classes, and not having digester Factory methods available (unless digester is also subclassed). Of course all this is just theory. Well, some of it has been implemented in a Ruby version of the digester I did. I haven't felt the enthusiasm to test out the idea, look for flaws, implement it, add unit tests, etc. for digester 1.x series. I certainly do intend to do *something* to address the existing CallMethodRule issue though for the digester 2.x series. [which has no release date planned yet]. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
