Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <415A9B5F.6070504@outerthought.org>
Date: Wed, 29 Sep 2004 13:24:15 +0200
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CForms: updating jxpath
References: <7557e99f0409290307c45c742@mail.gmail.com>
In-Reply-To: <7557e99f0409290307c45c742@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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