cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ellis Pritchard (JIRA)" <>
Subject [jira] Commented: (COCOON-2075) BrowserUpdateTransformer should not drop namespace declarations itself in any circumstance
Date Mon, 18 Jun 2007 12:11:25 GMT


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:
>             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
> <div xmlns="" 
>     xmlns:ft=""
>     xmlns:fi=""
>     xmlns:jx="">
>    <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.

View raw message