Carsten Ziegeler wrote:
hepabolu wrote:
Joerg Heinicke said the following on 23/5/07 20:03:
On 23.05.2007 13:07, hepabolu wrote:
+ I would comment (or even close-wontfix?) that bug with a
reference to the above conclusion from carsten. Just in case
somebody would want to apply the patch without giving it more
thought...
I just added a comment.
Using the param is an appropriate solution and the patch is no longer
valid. Since the issue (COCOON-1686) was especially created as patch
to COCOON-1671 I closed it, but added a comment and link from
COCOON-1671 to it.
Thanks. Sadly enough it still doesn't solve my problem.
I hope some of you can shed some light on this:
In flowscript I create the various cform files through pipelines (see
[1]).
When I read the source from a file by using the line marked with
[****X****] instead of the one below, the binding starts to work (I
get an error on expected BigDecimal vs received String, but that's a
different problem). This source file is created by displaying the
output of the pipeline of the line below in a browser and saving the
source of that output in a file.
If I see this correctly, the difference between the two solutions is
that in the not working case, the DOMBuilder is used to build the DOM
whereas in the working case, the serializer is used and the result is
then parsed again.
Perhaps you could solve the problem by tweaking the DOMBuilder and
setting some properties on the used transformer factory/handler?
Carsten,
I think you do see that correcctly!
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)
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)
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?
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?)
- or rewrite the whole form-binding-builder process to use sax :-)
(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 ? )
regards,
-marc
HTH
Carsten
