You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Helma van der Linden <h....@mi.unimaas.nl> on 2007/05/22 17:07:38 UTC
CForms binding with namespaces error - advice wanted
Guys,
once again I run into a problem with cforms binding with a namespaced
source.
Turns out that the namespace is not passed on to the
JXPathBindingManager. There are (at least?) 3 open JIRA issues on this
topic:
https://issues.apache.org/jira/browse/COCOON-1595
https://issues.apache.org/jira/browse/COCOON-1671
https://issues.apache.org/jira/browse/COCOON-1686
The last one provides some patches that are reported to work. It
basically add the following to JXPathBindingManager.createBinding:
// 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?
Any ideas?
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
hepabolu wrote
>
> 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>>"
>
Does this exception come from jxpath? If so, I think you somehow have to
make the prefixes known to jxpath.
HTH
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
Helma wrote:
> Carsten Ziegeler said the following on 23/5/07 21:43:
>> 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.
>
> As Marc said, you're right.
>
> As you suggested offline I've tried serializing the output of the
> pipelineUtil.toDOM to a file and do a diff. The result is: the files are
> identical except that elements with multiple attributes have a different
> order of the attributes.
>
> Just to be sure that I didn't disguise any errors by the way I saved the
> files, here's what I did [1].
>
> Notes:
> - pipeline is simple xml-generator + xsl-transformer + xml-serializer,
> all default stuff. The only thing different is the parameter of
> namespace prefix=true in cocoon.xconf for the xml-parser.
>
> - BTW this leads to NAMESPACE PREFIX!!!!!!!!!!!!!!!!!!!!!!!!!! lines in
> the console. Is that what you were referring to in your other post?
Yes, exactly that :) This has been removed in latest versions of
excalibur xmlutils (but apart from that debug msg the versions are
identical).
>
> So unless I have done the process of saving wrong, I don't see a
> difference between the two files.
Hmmm, I'm not sure again, but I think the dom streamer is rather tricky
and does some magic behind the scenes with namespace nodes. But I might
be mistaken.
Actually you have to compare the resulting dom trees, the one from the
pipelineutil and the one from the parser.
I would suggest streaming them with the usual jaxp stuff and not use the
domstreamer for this.
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
Carsten Ziegeler said the following on 23/5/07 21:43:
> 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.
As Marc said, you're right.
As you suggested offline I've tried serializing the output of the
pipelineUtil.toDOM to a file and do a diff. The result is: the files are
identical except that elements with multiple attributes have a different
order of the attributes.
Just to be sure that I didn't disguise any errors by the way I saved the
files, here's what I did [1].
Notes:
- pipeline is simple xml-generator + xsl-transformer + xml-serializer,
all default stuff. The only thing different is the parameter of
namespace prefix=true in cocoon.xconf for the xml-parser.
- BTW this leads to NAMESPACE PREFIX!!!!!!!!!!!!!!!!!!!!!!!!!! lines in
the console. Is that what you were referring to in your other post?
So unless I have done the process of saving wrong, I don't see a
difference between the two files.
Bye, Helma
-----
[1]
FILE1 = display above pipeline in firefox -> view page source -> copy &
paste to texteditor -> save
FILE2 =
var document = pipelineUtil.processToDOM("AddIDsPipeline/" +
formFileName, {});
_saveDocument(document, _makeTargetURI(documentURI));
_saveDocument(document, uri) {
...
resolver =
cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
source = resolver.resolveURI(uri);
var tf =
Packages.javax.xml.transform.TransformerFactory.newInstance();
if (source instanceof
Packages.org.apache.excalibur.source.ModifiableSource
&&
tf.getFeature(Packages.javax.xml.transform.sax.SAXTransformerFactory.FEATURE))
{
outputStream = source.getOutputStream();
var transformerHandler = tf.newTransformerHandler();
var transformer = transformerHandler.getTransformer();
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.INDENT,
"true");
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.METHOD,
"xml");
transformerHandler.setResult(new
Packages.javax.xml.transform.stream.StreamResult(outputStream));
var streamer = new
Packages.org.apache.cocoon.xml.dom.DOMStreamer(transformerHandler);
streamer.stream(document);
...
}
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
Carsten Ziegeler wrote:
> Helma wrote:
>>
>> That's what I'm slowly starting to realise. For proper XML validation
>> I do need it so I assumed the parser requires this too.
>>
>> That would partially explain why the binding file (without a
>> namespaceURI for 'oe') still maps to the source (in the source=file
>> situation). It would also explain the observations in
>>
>> https://issues.apache.org/jira/browse/COCOON-1671
>>
>> i.e. if the prefix is the same with a matching or a different
>> namespaceURI it binds, but if the prefix is different but the
>> namespaceURI is identical it fails.
>>
>> So how should this be solved then?
>>
> I think there are two areas:
>
> The first one is the parsing of the binding. We have to ensure that the
> namespace prefixes are correctly send to the cforms component parsing
> the binding. So we should see that there is no namespace prefix
> inbetween. Actually, I fear, we can't ensure this in general. So perhaps
> in these cases a workaround is required and you have to add a dummy
> attribute somewhere in the binding, like <fb:... oe:something="dummy">.
> This is not great, but hopefully solves this problem.
>
good idea,
on the other hand we are looking here at xml representations on file, right?
so while this approach would force some xml-serializer to include the
xmlns declaration it doesn't really guarantee that the SAX-stream will
suddenly add a xmlns:oe="..." as _attribute_ to the sax startElement
method, does it?
(which is what we forced on the sax parser by adding the 'dangerous'
parameter)
personally I think the safer bet is to change the harvesting logic of
the xmlns declarations from the DOM tree
(although it is more work)
> Now, the second area is more complicated. When cforms parses a binding
> it should parse the paths and test them for namespaces and if these
> namespaces are properly defined - if not, throw exception.
> When the binding is applied, the namespaces have to be checked, if the
> uri's are the same. This should then work even if different prefixes are
> used. I looked into namespaces and jxpath a long time ago and I think to
> remember that there were problems; so this could get ugly :(
>
there were, but as mentioned in the bug (see my previous post), they
should be solved in jxpath 1.2
> I think this is something for our cforms and jxpath experts!
>
> Carsten
>
regards,
-marc=
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
Helma wrote:
>
> That's what I'm slowly starting to realise. For proper XML validation I
> do need it so I assumed the parser requires this too.
>
> That would partially explain why the binding file (without a
> namespaceURI for 'oe') still maps to the source (in the source=file
> situation). It would also explain the observations in
>
> https://issues.apache.org/jira/browse/COCOON-1671
>
> i.e. if the prefix is the same with a matching or a different
> namespaceURI it binds, but if the prefix is different but the
> namespaceURI is identical it fails.
>
> So how should this be solved then?
>
I think there are two areas:
The first one is the parsing of the binding. We have to ensure that the
namespace prefixes are correctly send to the cforms component parsing
the binding. So we should see that there is no namespace prefix
inbetween. Actually, I fear, we can't ensure this in general. So perhaps
in these cases a workaround is required and you have to add a dummy
attribute somewhere in the binding, like <fb:... oe:something="dummy">.
This is not great, but hopefully solves this problem.
Now, the second area is more complicated. When cforms parses a binding
it should parse the paths and test them for namespaces and if these
namespaces are properly defined - if not, throw exception.
When the binding is applied, the namespaces have to be checked, if the
uri's are the same. This should then work even if different prefixes are
used. I looked into namespaces and jxpath a long time ago and I think to
remember that there were problems; so this could get ugly :(
I think this is something for our cforms and jxpath experts!
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
hepabolu wrote:
> Marc Portier said the following on 24/5/07 17:35:
>> we could start off by checking some more
>>
>> 1/ can jxpath in fact handle namespaces correctly as described above
>> ( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396
>> the orginal reporter of the issue states that this is the case, so we
>> can take it from there of course)
>
> right.
>
>> 2/ are indeed the ns-maps inside the CommonAttributes objects on each
>> JXPathBinding base correctly filled in (I suggest dumping those in
>> log-debug statements during binding to verify in the various cases)
>
> No. I've done step-by-step debugging on this and the CommonAttributes
> are empty or null (can't remember exactly). In any case, no namespaces
> are available. In fact CommonAttributes calls addLocalNSAttributes (or
> something similar) which in turn calls Element.getAttributes() which
> doesn't return any namespaces.
>
yes, the namespace-prefix param on the parser does not guarantee that in
all cases pipelines will keep producing xmlns declarations as attributes
(only directly atop the parser we have that guarantee)
> I can't say whether that's due to a flaw in addLocalNSAttributes or
> because I was processing the binding generated through pipelineUtil.toDOM.
>
I suspect the latter
>> if those ns-declaration-maps are empty when they should not, then we
>> should fix the binding first to populate them correctly:
>>
>> - probably follow the path of fixing DomHelper to use the
>> lookupNamespaceURI() method in combo with some xpath parsing as I
>> suggested earlier)
>
ok, well it is probably rather 'bypass' the domhelper then fix
what we do now is ask (via the domhelper) to list ALL namespaces it can
find on an element (locally or inheritted) and then remember those in
the common-attributes
we do this based on the assumption that the xmlns-declarations are
available in the DOM as attributes, an assumption that you proved not
always to be true
to my knowledge there is no method in the DOM that will return you the
same information (list of all known ns-declarations)
There is however (already mentioned) node.lookupNamespaceURI(prefix)
which (according to javadoc) will resolve a given prefix to the bound
ns-uri in the context of any given node
So rather then list all the namespaces on the xml-element we could use
this to remember only the namespaces we need inside the bindings @path
statement. For that however we need to know which prefixes are used
inside the @path statement (hence my previous remark on a need to parse
those)
again there are assumptions in this approach
- sax-pipelines should not be hiding namespace-prefix-binding events
- the dom-trees (built from sax events) should be tested to be
correctly resolving the inheritence/overwrite of namespaces in the
result of the node.lookupNamespaceURI()
and more fundamentally:
code-wise these xml manipulations have been applicable for all bindings
(hence the name -common- attributes) in this case however there might be
(not sure) binding-specific structures that are declaring @path-like
attributes which should be parsed for more prefixes to list....
HTH,
-marc=
> If you could be more specific in how I should go about doing this, I'd
> have another look tomorrow...eh, later today. ;-)
>
>> - or stop joking about it and do the sax rewrite :-)
>
> Just wondering: is this 2.1.X only or does it affect 2.2 as well?
>
>
> Bye, Helma
>
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
Marc Portier said the following on 24/5/07 17:35:
> we could start off by checking some more
>
> 1/ can jxpath in fact handle namespaces correctly as described above
> ( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396
> the orginal reporter of the issue states that this is the case, so we
> can take it from there of course)
right.
> 2/ are indeed the ns-maps inside the CommonAttributes objects on each
> JXPathBinding base correctly filled in (I suggest dumping those in
> log-debug statements during binding to verify in the various cases)
No. I've done step-by-step debugging on this and the CommonAttributes
are empty or null (can't remember exactly). In any case, no namespaces
are available. In fact CommonAttributes calls addLocalNSAttributes (or
something similar) which in turn calls Element.getAttributes() which
doesn't return any namespaces.
I can't say whether that's due to a flaw in addLocalNSAttributes or
because I was processing the binding generated through pipelineUtil.toDOM.
> if those ns-declaration-maps are empty when they should not, then we
> should fix the binding first to populate them correctly:
>
> - probably follow the path of fixing DomHelper to use the
> lookupNamespaceURI() method in combo with some xpath parsing as I
> suggested earlier)
If you could be more specific in how I should go about doing this, I'd
have another look tomorrow...eh, later today. ;-)
> - or stop joking about it and do the sax rewrite :-)
Just wondering: is this 2.1.X only or does it affect 2.2 as well?
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
hepabolu wrote:
> Carsten Ziegeler said the following on 24/5/07 16:14:
>> Helma wrote
>>>
>>> Yes. Source is:
>>>
>>> <oe:version xmlns:oe="openEHR/v1/Version"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:type="ORIGINAL_VERSION">
>>>
>>> So in fact I want the first line of the binding file to bind to
>>> /oe:version
>>>
>>> I don't think there are unused prefixes in both binding and source.
>>>
>> Ah, sorry, I meant are you really using the prefix in the binding file?
>> Using the prefix inside of an attribute (like the path attribute) does
>> actually not use the prefix. This is just arbitrary text for the parser.
>
> That's what I'm slowly starting to realise. For proper XML validation I
> do need it so I assumed the parser requires this too.
>
> That would partially explain why the binding file (without a
> namespaceURI for 'oe') still maps to the source (in the source=file
> situation). It would also explain the observations in
>
> https://issues.apache.org/jira/browse/COCOON-1671
>
> i.e. if the prefix is the same with a matching or a different
> namespaceURI it binds, but if the prefix is different but the
> namespaceURI is identical it fails.
>
I'm not sure, but to my knowledge this effect is because jxpath falls
back to qname binding when it doesn't have the correct ns bindings on
the context
here is what I think is happening:
IF jxpath gets
- on a context with some ns declared: [x=uri1, y=uri2]
- a call to resolve an xpath: /z:whatever
then it first tries to find a ns binding for the 'z' prefix, and since
that one isn't there, then just assumes 'z:name' to be matched as a qname
so it will find such z:name regardless of whatever ns declaration there
would be in the xml-document it is querying for z
(we could argue if this is a bug, but I think this fallback makes
perfect sense for jxpath in order to support lookups that are not ns-aware)
however IF all namespaces are declared I would assume jxpath to be
working fully ns-aware, ie
IF jxpath gets
- on a context with some ns declared: [x=uri1, y=uri2]
- a call to resolve an xpath: /x:whatever
then it will find the node 'whatever' even if it is present in the xml
with prefix 'other' as long as xmlns:other'"uri1" is declared in the
target xml being searched
now for all this to work inside the binding-setup it needs to keep track
of all the namespace-declarations in the binding file in order to pass
them down to the jxpath context before asking it to resolve the @path of
the binding at hand
my guess is that since we don't seem to control the namespace-prefix
usage on the various parsers into play we sometimes get empty
ns-declaration sets, thus no ns info on the jxpath context, thus binding
failures, or rather lucky shot successes if the ns prefixes happen to match
> So how should this be solved then?
>
we could start off by checking some more
1/ can jxpath in fact handle namespaces correctly as described above
( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396
the orginal reporter of the issue states that this is the case, so we
can take it from there of course)
2/ are indeed the ns-maps inside the CommonAttributes objects on each
JXPathBinding base correctly filled in (I suggest dumping those in
log-debug statements during binding to verify in the various cases)
if those ns-declaration-maps are empty when they should not, then we
should fix the binding first to populate them correctly:
- probably follow the path of fixing DomHelper to use the
lookupNamespaceURI() method in combo with some xpath parsing as I
suggested earlier)
- or stop joking about it and do the sax rewrite :-)
regards,
-marc=
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
Carsten Ziegeler said the following on 24/5/07 16:14:
> Helma wrote
>>
>> Yes. Source is:
>>
>> <oe:version xmlns:oe="openEHR/v1/Version"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:type="ORIGINAL_VERSION">
>>
>> So in fact I want the first line of the binding file to bind to
>> /oe:version
>>
>> I don't think there are unused prefixes in both binding and source.
>>
> Ah, sorry, I meant are you really using the prefix in the binding file?
> Using the prefix inside of an attribute (like the path attribute) does
> actually not use the prefix. This is just arbitrary text for the parser.
That's what I'm slowly starting to realise. For proper XML validation I
do need it so I assumed the parser requires this too.
That would partially explain why the binding file (without a
namespaceURI for 'oe') still maps to the source (in the source=file
situation). It would also explain the observations in
https://issues.apache.org/jira/browse/COCOON-1671
i.e. if the prefix is the same with a matching or a different
namespaceURI it binds, but if the prefix is different but the
namespaceURI is identical it fails.
So how should this be solved then?
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
Helma wrote
>
> Yes. Source is:
>
> <oe:version xmlns:oe="openEHR/v1/Version"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:type="ORIGINAL_VERSION">
>
> So in fact I want the first line of the binding file to bind to /oe:version
>
> I don't think there are unused prefixes in both binding and source.
>
Ah, sorry, I meant are you really using the prefix in the binding file?
Using the prefix inside of an attribute (like the path attribute) does
actually not use the prefix. This is just arbitrary text for the parser.
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
Carsten Ziegeler said the following on 24/5/07 15:57:
> hepabolu schrieb:
>>>> So you can't rely that you get the namespace attributes in the dom
>>>> builder.
>>
>> I think this is where things go wrong.
>>
>> Note that both binding file and source are generated with a pipeline
>> and pipelineUtil.toDOM.
>>
>> I've done some debugging into pipelineUtil.toDOM and this is what I
>> found:
>> - binding file has all the namespaces in pipeline. This is confirmed
>> because I can save the output of the pipeline and see the namespaces
>> in the root element:
>>
>> <fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
>> xmlns:oe="openEHR/v1/Version" path="/oe:version">
>>
>> - After returning from SourceUtil.toDOM (which uses the default
>> DOMBuilder()), the only namespace left is
>> fb="http://apache.org/cocoon/forms/1.0#binding".
>> Attributes of this node only holds 'path=/oe:version'.
>>
>> - This is true for the source=pipeline situation as well: only the
>> oe="openEHR/v1/Version" is left.
>>
>> - The source=file situation has all namespaces in the attributes.
>>
>> I can understand that in the situation of source=pipeline there cannot
>> be any matching because the oe namespace is not known in the binding
>> file. However, this is also true for the situation of source=file and
>> there matching happens on various fb:context until it fails on a
>> difference in datatype.
>>
>> What I also don't understand is the fact that putting the
>> source=pipeline through the savedocument function as I did this
>> morning, gives me all the namespaces back.
>>
>> I'm not sure if this helps in the discussion and I have no clue on how
>> to solve this.
>>
>> Anyone?
>>
> I must say that this is all a little bit strange to me as well. Now, are
> you using the prefix oe somewhere in the xml? The prefix fb is definitly
> used, so it might be that there is some optimization filtering unused
> prefixes? Just a wild guess.
Yes. Source is:
<oe:version xmlns:oe="openEHR/v1/Version"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ORIGINAL_VERSION">
So in fact I want the first line of the binding file to bind to /oe:version
I don't think there are unused prefixes in both binding and source.
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
hepabolu schrieb:
>>> So you can't rely that you get the namespace attributes in the dom
>>> builder.
>
> I think this is where things go wrong.
>
> Note that both binding file and source are generated with a pipeline and
> pipelineUtil.toDOM.
>
> I've done some debugging into pipelineUtil.toDOM and this is what I found:
> - binding file has all the namespaces in pipeline. This is confirmed
> because I can save the output of the pipeline and see the namespaces in
> the root element:
>
> <fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
> xmlns:oe="openEHR/v1/Version" path="/oe:version">
>
> - After returning from SourceUtil.toDOM (which uses the default
> DOMBuilder()), the only namespace left is
> fb="http://apache.org/cocoon/forms/1.0#binding".
> Attributes of this node only holds 'path=/oe:version'.
>
> - This is true for the source=pipeline situation as well: only the
> oe="openEHR/v1/Version" is left.
>
> - The source=file situation has all namespaces in the attributes.
>
> I can understand that in the situation of source=pipeline there cannot
> be any matching because the oe namespace is not known in the binding
> file. However, this is also true for the situation of source=file and
> there matching happens on various fb:context until it fails on a
> difference in datatype.
>
> What I also don't understand is the fact that putting the
> source=pipeline through the savedocument function as I did this morning,
> gives me all the namespaces back.
>
> I'm not sure if this helps in the discussion and I have no clue on how
> to solve this.
>
> Anyone?
>
I must say that this is all a little bit strange to me as well. Now, are
you using the prefix oe somewhere in the xml? The prefix fb is definitly
used, so it might be that there is some optimization filtering unused
prefixes? Just a wild guess.
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
>> So you can't rely that you get the namespace attributes in the dom
>> builder.
I think this is where things go wrong.
Note that both binding file and source are generated with a pipeline and
pipelineUtil.toDOM.
I've done some debugging into pipelineUtil.toDOM and this is what I found:
- binding file has all the namespaces in pipeline. This is confirmed
because I can save the output of the pipeline and see the namespaces in
the root element:
<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
xmlns:oe="openEHR/v1/Version" path="/oe:version">
- After returning from SourceUtil.toDOM (which uses the default
DOMBuilder()), the only namespace left is
fb="http://apache.org/cocoon/forms/1.0#binding".
Attributes of this node only holds 'path=/oe:version'.
- This is true for the source=pipeline situation as well: only the
oe="openEHR/v1/Version" is left.
- The source=file situation has all namespaces in the attributes.
I can understand that in the situation of source=pipeline there cannot
be any matching because the oe namespace is not known in the binding
file. However, this is also true for the situation of source=file and
there matching happens on various fb:context until it fails on a
difference in datatype.
What I also don't understand is the fact that putting the
source=pipeline through the savedocument function as I did this morning,
gives me all the namespaces back.
I'm not sure if this helps in the discussion and I have no clue on how
to solve this.
Anyone?
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
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=
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
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
>
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
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?
HTH
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
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.
When I use the code as is below (i.e. the source is read from a
pipeline) the binding silently fails with a debug message in the log files:
PoolThread-4/ContextJXPathBinding: non-existent path: skipping
ContextJXPathBinding [xpath=/oe:version]
(oe:version is the root element).
Both binding and source file have the namespace set:
<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
xmlns:oe="openEHR/v1/Version" path="/oe:version">
and
<oe:version xmlns:oe="openEHR/v1/Version">
Anyone?
Thanks.
Bye, Helma
[1]
showmyform() {
var formFileName = cocoon.parameters["filename"];
/* Generate the template from a pipeline */
var formDisplay = "FormTemplatePipeline/" + formFileName;
/* Generate the model from a pipeline */
var pipelineUtil =
cocoon.createObject("org.apache.cocoon.components.flow.util.PipelineUtil");
var modelDoc = pipelineUtil.processToDOM("FormModelPipeline/"+
formFileName, {}).getDocumentElement();
/* Generate the binding from a pipeline */
var bindingDoc = pipelineUtil.processToDOM("FormBindingPipeline/" +
formFileName, {}).getDocumentElement();
//var bindingDoc = FORMDIR + "test-bloodfilmBinding.xml";
var form = new Form(modelDoc);
form.createBinding(bindingDoc);
/* Generate the result file */
var formResult = formFileName + "Result.jx";
// get the documentURI parameter from the sitemap which contains the
// location of the file to be edited
var documentURI = cocoon.parameters["documentURI"];
// parse the document to a DOM-tree
//[****X****]var document = _loadDocument(documentURI);
var document = pipelineUtil.processToDOM("AddIDsPipeline/" +
formFileName, {});
// bind the document data to the form
form.load(document.getDocumentElement());
// show the form to the user until it is validated successfully
form.showForm(formDisplay);
// bind the form's data back to the document
form.save(document);
cocoon.sendPage(formResult);
}
_loaddocument(uri){
.....
parser =
cocoon.getComponent(Packages.org.apache.excalibur.xml.dom.DOMParser.ROLE);
resolver =
cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
source = resolver.resolveURI(uri);
print ("sourceURI=" + source.getURI());
var is = new
Packages.org.xml.sax.InputSource(source.getInputStream());
is.setSystemId(source.getURI());
return parser.parseDocument(is);
......
}
Re: CForms binding with namespaces error - advice wanted
Posted by Joerg Heinicke <jo...@gmx.de>.
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.
Jörg
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
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.
Re: CForms binding with namespaces error - advice wanted
Posted by Marc Portier <mp...@outerthought.org>.
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 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...
regards,
-marc=
Re: CForms binding with namespaces error - advice wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
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...
HTH
Carsten
Re: CForms binding with namespaces error - advice wanted
Posted by hepabolu <he...@gmail.com>.
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?
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Posted by Joerg Heinicke <jo...@gmx.de>.
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.
Joerg