Community
Participate
Working Groups
Created attachment 131972 [details] patch http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/Element.html#getAttributeNS_java.lang.String__java.lang.String_ Currently, our implementation of Element#getAttributeNS returns null when the attribute doesn't exist. It should be returning an empty string.
Created attachment 131973 [details] testcases Contributing some basic testcases to get us started.
Nitin, could you please review this. I would like to try to get this in for 3.0.5 since it seems like a spec conformity issue.
Nick, just a word of caution: this "may" cause breakage in downstream code. This is a known issue, getAttribute suffers from the same deficiency, and there may even be an exisiting bug or enhancement for it. I would think that it is probably safer to address this in 3.2. Just my 0.2c.
Created attachment 131977 [details] patch with changes to getAttribute as well As Valentin mentioned, getAttribute returns null. Updated to adjust for this as well. Might have to tread lightly if this does affect users upstream.
I agree with Valentin on this one, purely from a maintenance release standpoint. Anyone relying on the broken behavior would have zero time to adjust with a maintenance release, and maintenance releases have to be compatible, even if it means being wrong in this case. It's also too late for 3.1, but 3.2 is fair game. When the time comes, be sure to create a New Help for Old Friends V and highlight this change.
You will want to run the DOM test suite as well that will be added to CVS later this week: https://bugs.eclipse.org/bugs/show_bug.cgi?id=214439
DOM Test suite is now in CVS.
I agree with the basic statement opening this bug ... "Currently, our implementation of Element#getAttributeNS returns null when the attribute doesn't exist. It should be returning an empty string" But, to go further, it should actually be returning a 'defaultValue' if one has been defined for that attribute, right? See bug 152690. I'm just commenting and cross-referencing here since if we are going to (potentially) break adopters to bring the API (partially) up to spec, maybe we should take it all the way to spec? Most would probably want to "check their code" once, instead of twice ... though I admit fixing bug 152690 would likely be more work (both to implement, and for adopters to fix). Feel free to educate me if I've misunderstood.
Created attachment 149383 [details] patch with cache Based on David's comments I've tweaked the patch a bit. Now, instead of just returning an empty string, we'll look up a default value. The one exception is for getAttributeNS(). The content model currently only keys off of the local name, thus causing any attributes with the same local name but different namespaces to be overwritten with the last one.
Valentin and Nitin, if either of you had any comments over this patch, I'd welcome them. Thanks.
Created attachment 149483 [details] path with access-order cache Cache now uses access-order.
I believe this can be resolved.
See bug 293712 for one example of the unintended side effects of this fix. I'm sure there will be others. (But, to be clear, I do think its the right thing to do still).
*** Bug 152690 has been marked as a duplicate of this bug. ***
WTP 3.3.0M6 returns null for undefined attributes again. Please, reopen this bug. STEPS TO REPRODUCE: 1. Create new Dynamic Web Project 2. Create NewFile.jsp page with one line inside: <html></html> 3. Check 'id' attribute of the <html> element programmatically (call htmlElement.getAttribute("id")). ACTUAL RESULT: htmlElement.getAttribute("id") returns null. EXPECTED RESULT: htmlElement.getAttribute("id") returns "". It seems like this is caused by the recent changes in org.eclipse.wst.xml.core.internal.document.ElementImpl.getAttribute(String name): lines String defaultValue = getDefaultValue(name); return (defaultValue != null) ? defaultValue : NodeImpl.EMPTY_STRING; were replaced by return getDefaultValue(name, NodeImpl.EMPTY_STRING); , but the method getDefaultValue(String, String) may return null.
(In reply to comment #15) > WTP 3.3.0M6 returns null for undefined attributes again. Please, reopen this > bug. > > STEPS TO REPRODUCE: > 1. Create new Dynamic Web Project > 2. Create NewFile.jsp page with one line inside: > <html></html> > 3. Check 'id' attribute of the <html> element programmatically (call > htmlElement.getAttribute("id")). > ACTUAL RESULT: > htmlElement.getAttribute("id") returns null. > EXPECTED RESULT: > htmlElement.getAttribute("id") returns "". > > It seems like this is caused by the recent changes in > org.eclipse.wst.xml.core.internal.document.ElementImpl.getAttribute(String > name): > lines > String defaultValue = getDefaultValue(name); > return (defaultValue != null) ? defaultValue : NodeImpl.EMPTY_STRING; > were replaced by > return getDefaultValue(name, NodeImpl.EMPTY_STRING); > , but the method getDefaultValue(String, String) may return null. Yador, the recent change is due to bringing the underlying DOM changes in line with the W3C DOM Level 1 specification. Please see the following reference. http://www.w3.org/TR/DOM-Level-1/level-one-core.html#ID-637646024
(In reply to comment #16) > Yador, the recent change is due to bringing the underlying DOM changes in line > with the W3C DOM Level 1 specification. Please see the following reference. > > http://www.w3.org/TR/DOM-Level-1/level-one-core.html#ID-637646024 Hey Dave, If you were interested, we addressed the null return value in Bug 341515. It is possible for the implied value from a CMDataType to return null for getImpliedValue(), which wasn't accounted for.
