Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: 26 Sep 2002 11:09:20 -0000
Message-ID: <20020926110920.10099.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 13022]  -
    Pass namespace URI and name args to the Rule methods

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13022>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13022

Pass namespace URI and name args to the Rule methods


------- Additional Comments From cmlenz@apache.org  2002-09-26 11:09 -------
First of all, thanks for looking at this :-)

However, I don't agree with your analysis.

The parameter stack is (IMHO) a kind of hackish way of enabling collaboration
between CallMethodRule and CallParamRule. It has nothing to do with the state of
a rule in general (the state of a rule should always be stored in it's own
instance variables). A better way to enable rule collaboration is out of the
scope of this bug, however ;-).

Second, when we talk about rule state, we need to differentiate between state
regarding the input (i.e. the context in the XML document being parsed) and the
output (i.e. the object and parameter stacks). Originally, the rules got
information about the input state through the method args, like in
begin(Attributes) and body(bodyText). Later in the development of Digester the
need has emerged to also access the current element's name, specifically in the
BeanPropertySetterRule. At that time, changing the Rule class was avoided, and
the immediate need was fulfilled by directly accessing the "match" instance
variable of Digester and extracting the last segment. Digester does provide the
method getCurrentElementName() that does the same thing, but this method is also
a result of Rule not having the interface I propose here. Finally, as namespace
support was added relatively late in the process, their is as of today no way
for a Rule to get the current namespace URI.

There are two options to achieve giving the rules more information about the
input document context:
1. Let Digester maintain the context using a stack (Element or a more
lightweight class, whatever), and have the rule access that stack, or
2. Pass information about the current document context into the begin(), body()
and end() methods of the rule.

I see a lot of advantages about approach number 2.
- 90% of the current rules in Digester don't *need* information about the input
context, so maintaining the Element stack would be a total waste of resources.
- The Rule methods begin(), body() and end() themselves, and their current
arguments (Attributes and bodyText), already inform the rule about the input
context.
- Rule implementations are more decoupled from Digester.
- Arguably, a rule shouldn't have access to the full input context (i.e. the
elements under the top element in the stack), it should only need to access
information about the element it was matched on
- As said before, the class Digester is already bloated

Sorry for the long explanation, I hope it is understandable.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>