CForms: updating jxpath

[Gianugo Rabellino <gi...@gmail.com>]

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,
-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: CForms: updating jxpath

[Sylvain Wallez <sy...@apache.org>]

Marc Portier wrote:

> There was an initial sharing of thought on this:
> http://marc.theaimsgroup.com/?t=109411811400002&r=1&w=2


<snip/>

> 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?)


You should take a look at o.a.c.util.jxpath.DOMFactory, which currently 
handles the namespaces by crawling up in the ancestor list up to finding 
either an element with the required prefix, or a xmlns:prefix declaration.

That algorithm can be used to determine the active namespace 
declarations at a given point in the binding definition file (e.g. on a 
<fb:value> element) to build the list of namespace declarations that 
have to be "transferred" over to JXPath.

As outlined by Marc, the modifications are likely to be limited to 
JXPathBindingBuilderBase and JXPathBindingBase through the use of 
CommonAttributes.

I was wondering also if we need to update all calls to 
JXPathContext.getRelativeContext(), but I think this isn't actually 
needed, because AFACIS these new contexts are created as part of a 
single binding instruction and therefore share the same namespace 
declarations as their parent context.

So updating 2 classes should be all what's needed to do.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: CForms: updating jxpath

[Marc Portier <mp...@outerthought.org>]

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/
mpo@outerthought.org                              mpo@apache.org