cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: CForms binding with namespaces error - advice wanted
Date Thu, 24 May 2007 12:27:52 GMT


Carsten Ziegeler wrote:
> 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.
> 

yeah sure,
I was just theoretically venturing down the path of being lazy to try 
and grasp the cost of such attitude in this case :-)

thx for showing us the possible dangers

>>
>> 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... :(
> 

for the inherited declarations the current solution already does some of 
that, so that might sound worse then it is...

in fact current DOM level actually allows to register 'userdata' on 
nodes, which could work as some smart cache of intermediate results (so 
we don't need to traverse all the way up to the root element each time)

(with that 'current DOM level' I assume that even while we keep being 
1.4 jvm compatible in cocoon, I guess we _are_ using (endorsing) the 
newest xmlapis, right?)

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

who? me?

>>
>> (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 :)
> 

Didn't do that, but I did notice that the current DOM Level has a 
lookupNamespaceURI(prefix) which could help out


big advantage:
   this should even prevent us from doing the tree traversal

but brings the additional work:
   we would need to parse the provided xpath statement (in the 
build-elm/@path attr) to look for potential ns-prefixes

   anyone knowing about an xpath parsing/tokenizing lib?
   (yeah, jxpath! but I don't know if it makes such intermediate results 
as the list of used namespaces publicly available, anyone else?)


(a naieve first stab on getting these pfxs is to look for any group of 
NCNAME [1]  chars leading up to a ':'  even if that would include false 
prefixes out of e.g string-values as in:
    @path="//oe:version[@label = 'x:y']"

which would suggest to lookup both 'oe' and 'x' ns-uris, the latter 
probably false, and even if it would yield a valid namespace, quite 
harmless)

[1] http://www.w3.org/TR/REC-xml-names/#NT-NCName


-marc=

Mime
View raw message