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
