HtmlUnit should support the W3C DOM API for DomNode and related classes. This would allow better integration of HtmlUnit with other tools and provide a consistent API for developers.
I have an initial estimate of the changes to the API that are NOT backwards compatible for adding W3C DOM support:
HtmlScript, HtmlOption
- public DomNode appendChild(final DomNode node) {
+ public Node appendChild(final Node node) {
HtmlPage
- public HtmlElement getDocumentElement() {
+ public Element getDocumentElement() {
public HtmlElement createElement(final String tagName) {
public Element createElement(final String tagName) {
public HtmlElement createElementNS(final String namespaceURI, final String qualifiedName) {
public Element createElementNS(final String namespaceURI, final String qualifiedName) {
public DomNode cloneNode(final boolean deep) {
public Node cloneNode(final boolean deep) {
DomNode
- public DomNode getLastChild() {
+ public Node getLastChild() {
public DomNode getParentNode() {
public Node getParentNode() {
public DomNode getPreviousSibling() {
public Node getPreviousSibling() {
public DomNode getNextSibling() {
public Node getNextSibling() {
public DomNode getFirstChild() {
public Node getFirstChild() {
public DomNode cloneNode(final boolean deep) {
public Node cloneNode(final boolean deep) {
public DomNode appendChild(final DomNode node) {
public Node appendChild(final Node node) {
HtmlElement
- public DomNode cloneNode(final boolean deep) {
+ public Node cloneNode(final boolean deep) {
Except for appendNode, these are all required to be changed due to the incompatible return type for the same method signature. Of course, these changes appear to all derived classes as well. The HtmlPage/Document issue I raised earlier appears to have already been fixed.
The question is, are these changes acceptable? The most common impact is to break code that uses these methods where the returned object is used as the derived class. It can be fixed by adding casts, or in my prototype I've added corresponding "Test" methods that return the derived type to avoid the cast, e.g., in HtmlPage:
public HtmlElement getDocumentElement() {
public Element getDocumentElement() {
public HtmlElement getTestDocumentElement() {
The only workaround to avoid the backwards incompatibility I've come up with is to implement a separate package that implements the W3C DOM API and wraps the com.gargoylesoftware.htmlunit.html package. That's a lot of classes.
These incompatible changes seem to me like an acceptable break for a 2.0 release. What do you think? Should I continue in this direction?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=742109
Originator: YES
I have an initial estimate of the changes to the API that are NOT backwards compatible for adding W3C DOM support:
HtmlScript, HtmlOption
- public DomNode appendChild(final DomNode node) {
+ public Node appendChild(final Node node) {
HtmlPage
- public HtmlElement getDocumentElement() {
+ public Element getDocumentElement() {
public Element createElement(final String tagName) {
public HtmlElement createElementNS(final String namespaceURI, final String qualifiedName) {
public Element createElementNS(final String namespaceURI, final String qualifiedName) {
public DomNode cloneNode(final boolean deep) {
DomNode
- public DomNode getLastChild() {
+ public Node getLastChild() {
public Node getParentNode() {
public DomNode getPreviousSibling() {
public Node getPreviousSibling() {
public DomNode getNextSibling() {
public Node getNextSibling() {
public DomNode getFirstChild() {
public Node getFirstChild() {
public DomNode cloneNode(final boolean deep) {
public Node cloneNode(final boolean deep) {
public DomNode appendChild(final DomNode node) {
HtmlElement
- public DomNode cloneNode(final boolean deep) {
+ public Node cloneNode(final boolean deep) {
Except for appendNode, these are all required to be changed due to the incompatible return type for the same method signature. Of course, these changes appear to all derived classes as well. The HtmlPage/Document issue I raised earlier appears to have already been fixed.
The question is, are these changes acceptable? The most common impact is to break code that uses these methods where the returned object is used as the derived class. It can be fixed by adding casts, or in my prototype I've added corresponding "Test" methods that return the derived type to avoid the cast, e.g., in HtmlPage:
The only workaround to avoid the backwards incompatibility I've come up with is to implement a separate package that implements the W3C DOM API and wraps the com.gargoylesoftware.htmlunit.html package. That's a lot of classes.
These incompatible changes seem to me like an acceptable break for a 2.0 release. What do you think? Should I continue in this direction?
Logged In: YES
user_id=950730
Originator: NO
I guess there is no objection.
As you said, these seems to be acceptable changes, that would be made sooner or later.
Please let us know if you need any help.
Logged In: YES
user_id=950730
Originator: NO
Closing, as most of DOM API is implemented.
Please test latest snapshot and advise if you have any issue.