cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Krishna Dudella" <krish...@gmail.com>
Subject Re: [jira] Updated: (COCOON-2075) BrowserUpdateTransformer corrupts content from template using a default namespace
Date Mon, 18 Jun 2007 14:28:44 GMT
How can I unsubscribe from this list ?

On 6/18/07, Ellis Pritchard (JIRA) <jira@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.
>
>

Mime
View raw message