cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ellis Pritchard (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts content from template using a default namespace
Date Mon, 18 Jun 2007 12:17:26 GMT

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


Mime
View raw message