Hi,
First of all, let me thank you for a great project. We like what you
are doing, and what you have done, and how you are doing it. We think our
decision to use Chiba as a part of our project will prove to be a good one.
The attached example Chiba XForms document exhibits some behavior which I
believe to be in error.
FWIW, I have run the same XForms code under the Release Candidate of
FormsPlayer, and it behaves the way I was expecting, so I am inclined to
believe there really is a Chiba bug. (Don't worry -- we're not planning on
using FormsPlayer. ;-)
This is the relevant part of the spec:
<http://www.w3.org/TR/xforms/slice7.html#expr-eval>
specifically under 7.4 Evaluation Context:
"The context node for non-outermost binding elements is the first node of the
binding expression of the immediately enclosing element. An element is
"immediately enclosing" when it is the first binding element node in the
node-set returned by the XPath expression ancestor::*. This is also referred to
as "scoped resolution"."
To my way of thinking, it should make no difference whether the _ancestor's_
binding is done via "ref" (which works just fine) or "bind" (which appears not
to).
More specifically, it would appear that the ancestors with the "bind" attribute
are treated as if they were not binding elements for the purposes of scoped
resolution.
By visual inspection, the problem must be related to the method:
org.chiba.xml.xforms.Binding getEnclosingBinding(XFormsElement)
There is some code:
ElementImpl elementImpl = (ElementImpl)parentNode;
Object o = elementImpl.getUserData();
if ((o != null) && o instanceof Binding) {
Binding binding = (Binding)o;
if (binding.getModelId().equals(modelId)) {
enclosingBinding = (Binding)o;
}
}
which must be failing to return the enclosingBinding when the enclosing binding
was done via "bind" rather than "ref".
Two possibilities come to mind:
- elements bound with "bind" don't have the userData as instanceof Binding
- the binding's model ID is not set correctly for either the current or
enclosing binding (unlikely IMO).
If the former, it will be a matter of tracking down where the Binding user data
is supposed to be set.
We are planning on setting up to build with the latest source, in which case,
we will probably quickly find out more precisely what is happening, and where
to address it. If so, we'll let you know if we do anything useful. In the
meantime, I would appreciate any feedback that would confirm my opinion.
It may well be that this is very easily addressed by someone more familiar with
the codebase. (It sounds like it ought to be.)
Although this particular XForms structure may seem a bit arcane, and there are
similar working ways to accomplish the same objective in Chiba, this particular
one makes our code-generation process much easier, and so we will probably
pursue a resolution rather than try to live with it.
Thanks for any input.
Regards,
Paul
Paul Miniato
Architect, ProLender Project
Credit Union Central of BC
<<bindContextBug.xhtml>>
bindContextBug.xhtml
Description: bindContextBug.xhtml
|
