There was an initial sharing of thought on this: http://marc.theaimsgroup.com/?t=109411811400002&r=1&w=2
below is quite sketchy and possibly incomplete, but should set you off (don't be shy to ask for more details)
I'm also working top-down, if you want to see all details first, then read bottom-up :-)
so starting here: http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingBase.java?rev=45990&root=Apache-SVN&view=auto
see this:
public final void loadFormFromModel(Widget frmModel, JXPathContext jxpc)
throws BindingException {
boolean inheritedLeniency = jxpc.isLenient();
applyLeniency(jxpc);
if (this.commonAtts.loadEnabled) {
doLoad(frmModel, jxpc);
}
jxpc.setLenient(inheritedLeniency);
}
around the setting-removing of the common attribute 'leniency'
we might now introduce applyNSDeclarations(jxpc) which should set them on the jxpath context (which is the new part of the jxpath API I don't know)
NOTES:
- there is a similar thing to do in the reciproce saveFormToModel
- i'm quite unsure about 'unregistring namespaces on the context' in this new jxpath (is it required?)
The new method could consult the this.commonAtts object for an array of namespace-declarations it needs to apply on the context. (possibly this is coded in two arrays of String[], or one Array of 2-string-Arrays, or an Array of some new NSDecl class that can hold the pfx and nsuri tupple, or... Go wild!)
in any case we're switching to: http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingBuilderBase.java?rev=43531&root=Apache-SVN&view=auto
The mentioned available 'array' of course assumes you add that to the JXPathBindingBuilderBase.CommonAttributes object.
--> following the final and non-private approach of the current members, this means you'ld need to pass it down in the constructor, and addapt the current constructor implementations to call this() new one with 'null'
Next on the list is making sure this new constructor gets called from getCommonAttributes(Element bindingElm) which is in the enclosing class JXPathBindingBuilder
Maybe you could extend the DOMHelper (already used over there) to inspect the dom-element at hand and immediately return your NS_declaration_array of choice that can then be passed down into the constructor to CommonAttributes.
Only remaining thing is then to find out how to find all namespace-declarations from a dom node?
(I suppose itterating through all attributes and finding out which ones are in the xmlns-namespace?)
hoping this gives you some overlook on the forest?
And just a teaser: Would be nice to have a sample or test alongside...
regards, -marc=
Gianugo Rabellino wrote:
I've come to the point, in several projects we have, where I could really use the new namespace-aware JXPath. I'm willing to help in the integration which should be quite transparent according to JXPath release notes. Indeed adding the new JXPath jar keeps samples working.
However, this is almost it. A first look at the o.a.c.f.b.*JXPath*
forest seems to show that it will be quite a bit of work to add
namespace registration all over the place. I could use some help on
where to start, it could well be that I'm missing the most simple and
effective solution, but the idea of keeping in sync namespace scopes
in the binding file with JXPath looks quite scary at a first look.
Anyone willing to help out?
Ciao,
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
