You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Ellis Pritchard (JIRA)" <ji...@apache.org> on 2007/06/07 12:47:25 UTC
[jira] Created: (COCOON-2075) BrowserUpdateTransformer should not
drop namespace declarations itself in any circumstance
BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance
------------------------------------------------------------------------------------------
Key: COCOON-2075
URL: https://issues.apache.org/jira/browse/COCOON-2075
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Ellis Pritchard
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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts content from template using a default namespace
Posted by Krishna Dudella <kr...@gmail.com>.
How can I unsubscribe from this list ?
On 6/18/07, Ellis Pritchard (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Ellis Pritchard updated COCOON-2075:
> ------------------------------------
>
> Attachment: (was: browser-update.xsl)
>
> > BrowserUpdateTransformer corrupts content from template using a default
> namespace
> >
> ---------------------------------------------------------------------------------
> >
> > Key: COCOON-2075
> > URL: https://issues.apache.org/jira/browse/COCOON-2075
> > Project: Cocoon
> > Issue Type: Bug
> > Components: Blocks: Ajax
> > Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current
> SVN)
> > Reporter: Ellis Pritchard
> > Attachments: browser-update.xsl
> >
> >
> > 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 message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (COCOON-2075) BrowserUpdateTransformer should not
drop namespace declarations itself in any circumstance
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505789 ]
Ellis Pritchard commented on COCOON-2075:
-----------------------------------------
The 'fix' above did not hold: changes in the template such as adding a new custom jx macro caused the problem to occur, even with the fix.
However, using xhtml: prefixes in the form template did continue to work; again, it's just the default namespace which is broken.
Instead of the BrowserUpdateTransformer, using the functionally equivalent XSL stylesheet (attached) has none of the ill effects I've experienced; I can use the default namespace for XHTML in the template, and AJAX (and non-AJAX) works as expected.
This would seem to prove to me that there *is* a problem with BrowserUpdateTransformer and the default namespace.
Workaround: use the stylesheet instead of the transformer.
> BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance
> ------------------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2075) BrowserUpdateTransformer
should not drop namespace declarations itself in any circumstance
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505786 ]
Ellis Pritchard edited comment on COCOON-2075 at 6/18/07 5:04 AM:
------------------------------------------------------------------
Stylesheet which is functionally equivalent to BrowserUpdateTransformer.java
<map:transform type="xslt" src="browser-update.xsl">
<map:parameter name="ajax" value="{request-param:cocoon-ajax}"/>
</map:transform>
was:
Stylesheet which is functionally equivalent to BrowserUpdateTransformer.java
> BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance
> ------------------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts
content from template using a default namespace
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ellis Pritchard updated COCOON-2075:
------------------------------------
Attachment: browser-update.xsl
Removed superfluous XHTML namespace.
> BrowserUpdateTransformer corrupts content from template using a default namespace
> ---------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2075) BrowserUpdateTransformer corrupts
content from template using a default namespace
Posted by "Andrew Savory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Savory closed COCOON-2075.
---------------------------------
Resolution: Fixed
Closed after discussion with Ellis. May need to be re-opened if others hit this...
> BrowserUpdateTransformer corrupts content from template using a default namespace
> ---------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11, 2.2
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts
content from template using a default namespace
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ellis Pritchard updated COCOON-2075:
------------------------------------
Attachment: (was: browser-update.xsl)
> BrowserUpdateTransformer corrupts content from template using a default namespace
> ---------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts
content from template using a default namespace
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ellis Pritchard updated COCOON-2075:
------------------------------------
Summary: BrowserUpdateTransformer corrupts content from template using a default namespace (was: BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance)
Changed title to be less prescriptive.
> BrowserUpdateTransformer corrupts content from template using a default namespace
> ---------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2075) BrowserUpdateTransformer should not
drop namespace declarations itself in any circumstance
Posted by "Ellis Pritchard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ellis Pritchard updated COCOON-2075:
------------------------------------
Attachment: browser-update.xsl
Stylesheet which is functionally equivalent to BrowserUpdateTransformer.java
> BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance
> ------------------------------------------------------------------------------------------
>
> Key: COCOON-2075
> URL: https://issues.apache.org/jira/browse/COCOON-2075
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Ajax
> Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Attachments: browser-update.xsl
>
>
> 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.