[
https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790191#action_12790191
]
Ludger Bünger commented on XERCESJ-1407:
----------------------------------------
Hi Michael,
I am not sure what exactly you are referring to by "a lot more going on".
I just had a look and found that all changes in HTMLBuilder are actually not
related to renaming: calling document.createText or
document.createProcessingInstruction instead of new TextImpl / new
ProcessingInstructionImpl, but this has been in the first patch too.
What I added is the following:
My original proposal had an internal method boolean canRenameElement() upon
CoreDocumentImpl returning true for the standard XML implementation and false
for HTML/WMLDocumentImpl.
Thus, if renameNode has been called upon HTML/WML documents, it never called
ElementImpl.rename but instead always used createElement to replace the element
while for XML documents a non-replacing rename was performed.
This is to ensure that instances of ParagraphElementImpl renamed to H1 were
replaced by instances of HeadingElementImpl.
However it is not necessary to always replace the element for HTML/WML elements
when renaming:
Imagine an HTML H1 being renamed to an H2. In this case it is perfectly ok to
do a non-replacing rename since the element can keep it's class
HeadingElementImpl.
So I added a few parameters to the canRenameElement method such that the
HTML/WMLDocumentImpl can query their internal class creation logic to determine
whether the would-be-created element would be of the same class as the
to-be-renamed element instance and give their permission whether renaming the
element is ok or whether replacing the element is required.
That's it the difference.
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: RenameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but
> this issue is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether
> renaming a node would cause a change of node implementation type, i.e.
> whether an instance of ElementImpl or AttributeImpl will be renamed such that
> it aquires a Namespace and thus needs to be converted to their respective NS
> counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl)
> and a namespace shall be set, xerces instantiates a new
> ElementNSImpl/AttNSImpl by calling the class constructor for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It
> should be PSVIElementNSImpl instead!
> Xerces should call document.createElement instead so the correct class will
> be instanciated.
> Actually I think it is a general problem that xerces sometimes call node
> constructors hard coded instead of using the document.create methods and
> suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is
> null, an internal rename method will be called upon the element/attribute
> implementation and the same node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for
> the HTML and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e.
> HTMLHeadingElementImpl or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element
> should be re-created using the createElement method of it's document
> implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element
> instances to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances
> of DocumentImpls) by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not,
> re-created elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
