cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: CForms binding with namespaces error - advice wanted
Date Fri, 25 May 2007 10:12:08 GMT


hepabolu wrote:
> Marc Portier said the following on 24/5/07 17:35:
>> we could start off by checking some more
>>
>> 1/ can jxpath in fact handle namespaces correctly as described above
>> ( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396 
>> the orginal reporter of the issue states that this is the case, so we 
>> can take it from there of course)
> 
> right.
> 
>> 2/ are indeed the ns-maps inside the CommonAttributes objects on each 
>> JXPathBinding base correctly filled in (I suggest dumping those in 
>> log-debug statements during binding to verify in the various cases)
> 
> No. I've done step-by-step debugging on this and the CommonAttributes 
> are empty or null (can't remember exactly). In any case, no namespaces 
> are available. In fact CommonAttributes calls addLocalNSAttributes (or 
> something similar) which in turn calls Element.getAttributes() which 
> doesn't return any namespaces.
> 

yes, the namespace-prefix param on the parser does not guarantee that in 
all cases pipelines will keep producing xmlns declarations as attributes
(only directly atop the parser we have that guarantee)

> I can't say whether that's due to a flaw in addLocalNSAttributes or 
> because I was processing the binding generated through pipelineUtil.toDOM.
> 

I suspect the latter

>> if those ns-declaration-maps are empty when they should not, then we 
>> should fix the binding first to populate them correctly:
>>
>> - probably follow the path of fixing DomHelper to use the 
>> lookupNamespaceURI() method in combo with some xpath parsing as I 
>> suggested earlier)
> 

ok, well it is probably rather 'bypass' the domhelper then fix

what we do now is ask (via the domhelper) to list ALL namespaces it can 
find on an element (locally or inheritted) and then remember those in 
the common-attributes

we do this based on the assumption that the xmlns-declarations are 
available in the DOM as attributes, an assumption that you proved not 
always to be true

to my knowledge there is no method in the DOM that will return you the 
same information (list of all known ns-declarations)

There is however (already mentioned) node.lookupNamespaceURI(prefix) 
which (according to javadoc) will resolve a given prefix to the bound 
ns-uri in the context of any given node


So rather then list all the namespaces on the xml-element we could use 
this to remember only the namespaces we need inside the bindings @path 
statement.  For that however we need to know which prefixes are used 
inside the @path statement (hence my previous remark on a need to parse 
those)



again there are assumptions in this approach

- sax-pipelines should not be hiding namespace-prefix-binding events
- the dom-trees (built from sax events)  should be tested to be 
correctly resolving the inheritence/overwrite of namespaces in the 
result of the node.lookupNamespaceURI()


and more fundamentally:

code-wise these xml manipulations have been applicable for all bindings 
(hence the name -common- attributes) in this case however there might be 
(not sure) binding-specific structures that are declaring @path-like 
attributes  which should be parsed for more prefixes to list....


HTH,
-marc=

> If you could be more specific in how I should go about doing this, I'd 
> have another look tomorrow...eh, later today. ;-)
> 
>> - or stop joking about it and do the sax rewrite :-)
> 
> Just wondering: is this 2.1.X only or does it affect 2.2 as well?
> 
> 
> Bye, Helma
> 

Mime
View raw message