cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hepabolu <hepab...@gmail.com>
Subject Re: CForms binding with namespaces error - advice wanted
Date Wed, 23 May 2007 11:07:55 GMT
Marc Portier said the following on 23/5/07 12:26:
> 
> 
> Carsten Ziegeler wrote:
>> hepabolu wrote:
>>> Joerg Heinicke said the following on 22/5/07 22:18:
>>>> On 22.05.2007 17:07, Helma van der Linden wrote:
>>>>
>>>>> // Create the SAX parser and set the features so it creates the 
>>>>> events we need
>>>>>                SAXParser parser = 
>>>>> (SAXParser)manager.lookup(SAXParser.ROLE);
>>>>>                if( parser instanceof Parameterizable ) {
>>>>>                    Parameters params = new Parameters();
>>>>>                    params.setParameter("namespace-prefixes","true");
>>>>>                    ((Parameterizable)parser).parameterize(params);
>>>>>                }
>>>>>
>>>>> but I'm wondering if that is the correct place to do that.
>>>>>
>>>>> OTOH, if it's done at a more global scale, would that have unwanted 
>>>>> side-effects?
>>>>
>>>> I don't know how SAXParsers are set up. But if they are pooled, even 
>>>> this change has side effects since the SAXParser is returned to the 
>>>> pool parameterized. Anyway this code smells. No idea how to do it 
>>>> otherwise though.
>>>
>>> Do you have any idea about what will happen if the parameter setting 
>>> is added at creation time of the SAXparser? I.e. will it affect 
>>> performance, memory consumption, behaviour of other parts of Cocoon?
>>>
>> The above code really smells :) It is even not guaranteed to work as 
>> passing a new set of paramters might not change all of the interal 
>> state of the component. This might be done in initialize() etc.
>> In addition if the parser would be thread safe it would change all 
>> uses of the parser. As noted above, even if the parser is pooled it's 
>> causing site effects.
>>
>> So, the only solution is to lookup the parser with the correct 
>> configuration which means adding another configuration to cocoon.xconf 
>> and giving it a different role. Then you look up exactly this instance 
>> and use it.
>> There is a minimal memory overhead with this solution but that can be 
>> neglected.
>>
>> I never liked the sax parser interface (and dom) because of this. It 
>> would be better if I could pass information like if the parser should 
>> validate etc. at runtime, e.g. by parse(InputSource, ParserParameters).
>> We could do this with the new parser interfaces in 2.2...
>>
> 
> Helma,
> 
> you might also want to check up on the second comment in that bug report
> haven't got time to delve into it, but it sounded as a more in depth 
> understanding of the root cause and an appropriate solution

I will see if that is true. For now I've applied the above patch to 
DomHelper (rather than JXPathBindingManager) and I now at least get the 
namespace reference from the source file.

However, the namespace attribute added to the binding file doesn't make 
it into the DomHelper.

This is what I get:

source:

<oe:version xmlns:oe="openEHR/v1/Version">
....
</oe:version>

binding file:

<fb:context path="/oe:version" xmlns:oe="openEHR/v1/Version">
....
</fb:context>

They don't match on oe:version (missing context path)

Debugging after applying the above patch showed that the namespace URI 
is present for the source file (before the patch is was null), but for 
the binding I get something like  "oe=<<unknown namespace>>"

Any ideas?

> + 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.

Mime
View raw message