cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: CForms binding with namespaces error - advice wanted
Date Thu, 24 May 2007 09:08:35 GMT
Marc Portier wrote:
> But taking it one step further: IMHO DomBuilder will use SAXParser down 
> below  somewheree to actually do the parsing. So just setting the 
> parameter namespace-prefix in the cocoon.xconf will ensure all 
> saxparsers in the pool to (correctly) have the parameter set... so both 
> cases should behave the same then. (and no ugly patching is needed)
Hmm, it's not nessarily the sax parser which is used. In this case, the 
dom builder gets the sax events directly from a pipeline. The pipeline 
might use the file generator (which uses the sax parser), but it also 
might use some other generator.
So you can't rely that you get the namespace attributes in the dom builder.

> 
> 
> Of course the logical remaining question is what about the side-effects 
> of this parameter-setting on the rest of cocoon (where SAXParser sounds 
> like a component under heavy use in every corner)
Yes, I asked this myself as well :) I think there was a drawback, that's 
why the default is "false" and there was a big println in the original 
code when the feature was turned on. But I actually do not know what 
this was :(

> 
> reading up on the meaning of the feature:
> http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html
> 
> it seems to result in sax-events (startElement) carrying the 
> xmlns:pfx=uri declarations as attributes!  This might sound as blasphemy 
> to the hardcore namespaced xml peeps around but it just ensures those 
> attributes to be available on the DOM elements that are input to the 
> form-binding-manager (who in turn needs those to instruct jxpath on what 
> namespaces are used on each level)
> 
> Logically I do not think this will lead to errors, as transformers and 
> serializers are typically targetted at reacting on specific attribites, 
> rather then scan and process them all in a way that would lead to faulty 
> results, no?
Hmm, I'm not sure here either. I know that over the past years I had to 
fix several transformers who did not expect an xmlns:something 
attribute. Ok, it's a bug in the transformer, but it shows the potential 
danger of turning this on by default. And as I explained above, I don't 
think that this will solve all problems as there are use cases where the 
sax parser is not used.
In addition, I don't think that this is a bug in the sax parser or the 
dom builder. I guess that this is more a problem down in the cforms code 
which does expect a specific dom format. I fear we have to fix the 
problem there.

> 
> Also, I would guess the resource/performance penalty of setting this 
> param to true isn't going to be too bad (taking the amount of 
> ns-declarations over useful data would be not too big in the typical 
> usage) but wouldn't know that for a fact. wdot?
> 
> 
> Other options (then setting the param to true) would be
> - to retrieve those xml-declarations from the DOM in some other way... 
> anyone? (can DOM nodes be asked to produce their available and/or 
> inherited ns-declarations?)
Yes, I think this is one way to go. I don't know of an easy way. But I 
think you have to go up the tree manually for that... :(

> - or rewrite the whole form-binding-builder process to use sax :-)
:) I was never that happy that forms uses dom internally :=) But as its 
working well and is used throughout the framework, I guess you are joking :)

> 
> (on the side: the fact that there exists an xpath 'namespace::' axis 
> leads me to believe that there should be some way of doing it on DOM as 
> well ? )
Good point. So we could check the xpath implementation :)

Carsten

Mime
View raw message