Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 120308

Summary:	we over notify for the case of "floating" attributes
Product:	[WebTools] WTP Source Editing	Reporter:	David Williams <david_williams>
Component:	wst.sse	Assignee:	wst.sse <wst.sse-inbox>
Status:	RESOLVED FIXED	QA Contact:	Nitin Dahyabhai <thatnitind>
Severity:	normal
Priority:	P2	CC:	itewksbu, nsand.dev
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description David Williams

2005-12-11 23:43:28 EST

We typicially base model notifiction on the dom model that contains an element or attribute. 

But, there's a "bug" in our logic such that if an attribute is created, but not yet part of a document model, we still notfiy the DOM model when its value is set. 
(This currently only effects attributes, I believe, but could effect elemeents when we completely implement notification at a micro level). 

The faulty logic is that we get the model from the owning document. But any attribute or element has the owenerDocument set when its created, whether or not its actually contained in any document. We should "walk up" the tree own parent nodes and see if the top most one is the same as the owning document, if it is, then the node/attribute is contained in that model, and we should notify that model, other wise not. 

We should be sure to well test performance implications. There will be a trade off of costing more to walk up tree, but improvments in sending less notifications.

Comment 1 David Williams

2005-12-11 23:58:17 EST

I've marked as "P2", be cause this bug could have lots of hard to find side effects.

Comment 2 Ian Tewksbury

2010-02-05 13:27:04 EST

While this bug maybe old I actually think its still worth looking into, but as David mentioned it would have to be carefully tested to be sure the trade off of less notifications for more work was actually a positive one.  There is even a comment note about this in the AttrImpl#setValue method.

Comment 3 Nick Sandonato

2012-09-26 18:41:39 EDT

This looks like it had been implemented at some point. In the AttrImpl#notifyValueChanged, it attempts to get the ownerElement's container document. It returns null if it's not part of a document, and the model is not notified of a change.