cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: CForms binding with namespaces error - advice wanted
Date Thu, 24 May 2007 07:29:17 GMT

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?

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:

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 ? )


> Carsten

View raw message