Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.10, 2.1.11, 2.2
-
None
-
None
-
Normal
Description
The org.apache.cocoon.ajax.BrowseUpdateTransformer does not pass on startPrefixMapping()/endPrefixMapping() in an ajaxRequest when not in a bu:replace; however this may mean that a namespace declared on an ancestor element of a bu:replace never gets declared in the output despite its use inside the bu:replace, and results in weird output behaviour after further processing, e.g. missing element names.
This problem seems to manifest itself only when using elements declared in the default namespace, e.g. if I wrap the whole form in a div with a default namespace declaration for xhtml:
<div xmlns="http://www.w3.org/1999/xhtml/"
xmlns:ft="http://apache.org/cocoon/forms/1.0#template"
xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<ft:form ...>
<div>
<span class="x">
<ft:widget ...>
The div and span elements will not be output correctly after further processing (empty element name) e.g.:
< >
< class="x">
You need to insert at least an identity XSL transform after the browser-update transformer to see this; a cocoon-view label doing a serialize to XML on the transformer itself does not seem to be enough; presumably it is the XSL processor that's going wrong when processing the corrupt output of the transformer, not the browser-update transformer itself.
The NamespacesTable used by the transformer declares the empty namespace (prefix="",ns="") itself, so html markup with no-namespace declaration (as in the forms-styling XSL) will work, but correct use an element in a default namespace will not work.
Adding default namespace declarations on the XHTML or the ft: elements themselves does not work (not being passed through somehow: jx/jx-macro problem?), however declaring a prefix for those elements does work, despite the mappings not being declared, which I presume is some kind of XML-legacy side-effect, outputting the effected tags with their prefix and local-name intact, although this might still produce problems.
In summary, elements declared in a default (uri but no-prefix) namespace are mangled by the transformer/pipeline because the namespace prefix is not declared. The lack of declaration may also be a general problem, depending on how your template file is marked up.
The fix is to remove the conditional from the startPrefixMapping() and endPrefixMapping() methods of BrowserUpdateTransformer, to allow all prefix declarations to reach the NamespaceTable, and allow it to do the optimization/de-duping work. I can't see that this could have any bad effects, since the NamespaceTable/RedundantNamespacesFilter is designed to handle all the namespace issues, which is why it is there in the first place.
This problem seems to manifest itself only when using elements declared in the default namespace, e.g. if I wrap the whole form in a div with a default namespace declaration for xhtml:
<div xmlns="http://www.w3.org/1999/xhtml/"
xmlns:ft="http://apache.org/cocoon/forms/1.0#template"
xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<ft:form ...>
<div>
<span class="x">
<ft:widget ...>
The div and span elements will not be output correctly after further processing (empty element name) e.g.:
< >
< class="x">
You need to insert at least an identity XSL transform after the browser-update transformer to see this; a cocoon-view label doing a serialize to XML on the transformer itself does not seem to be enough; presumably it is the XSL processor that's going wrong when processing the corrupt output of the transformer, not the browser-update transformer itself.
The NamespacesTable used by the transformer declares the empty namespace (prefix="",ns="") itself, so html markup with no-namespace declaration (as in the forms-styling XSL) will work, but correct use an element in a default namespace will not work.
Adding default namespace declarations on the XHTML or the ft: elements themselves does not work (not being passed through somehow: jx/jx-macro problem?), however declaring a prefix for those elements does work, despite the mappings not being declared, which I presume is some kind of XML-legacy side-effect, outputting the effected tags with their prefix and local-name intact, although this might still produce problems.
In summary, elements declared in a default (uri but no-prefix) namespace are mangled by the transformer/pipeline because the namespace prefix is not declared. The lack of declaration may also be a general problem, depending on how your template file is marked up.
The fix is to remove the conditional from the startPrefixMapping() and endPrefixMapping() methods of BrowserUpdateTransformer, to allow all prefix declarations to reach the NamespaceTable, and allow it to do the optimization/de-duping work. I can't see that this could have any bad effects, since the NamespaceTable/RedundantNamespacesFilter is designed to handle all the namespace issues, which is why it is there in the first place.