Bug 243799 - Analysis II

After looked the code, I think the problem is that the test2.xsd IDOModel only
includes test1.xsd IDOM Element at first time and the test2.xsd trigger its
listener to represent all elements in the Editor. If I changed something in the
test1.xsd IDOModel, it triggers its listener and represent itself. The
test1.xsd IDOModel, itself does not know it has been included by test2.xsd.
There is no way notify test2.xsd changing synchronously. Therefore, I guess we
need IDOM Manager which manages both IDOModel, but how ?.......I already posted
the question on Bigzilla. Waiting for Valentin's reply.

Bug 243799 - Analysis I

It takes a long time to make a second post in regard to Bug 243799. From now on, I will escalate my progress on investigating the bug and post my progress accordingly. Frankly as working on the bug in the past few days, I find out that the bug itself is so complicated. A complicated bug means I can learn more things from it.

At this time, I comprehend what causes the bug but I do not find a good way to fix it.

Let me go through this bug and explain what causes the bug

The description of the bug
We have two xml schema files (test1.xsd and test2.xsd) in a eclipse editor. When we include one of the schema files(test1.xsd) into the another schema file(test2.xsd), all the elements and attributes in the schema (test1.xsd) supposes to be included by the test2.xsd. It only works for one time when I intially include test1.xsd into test2.xsd.
Assuming that test2.xsd includes test1.xsd, if we modify or add some elements and attributes in the test1.xsd and all the elements and attributes in the test2.xsd must be modify or add because test2.xsd contains test1.xsd. The bug is that the elements in the test2.xsd is not responding as the elements in test1.xsd is changing from obersving the user interface.

Before we continue on, let us get concepts
The Document Object Model (DOM) is a platform- and language-independent standard object model for representing HTML or XML documents as well as an Application Programming Interface (API) for querying, traversing and manipulating such documents. (http://en.wikipedia.org/wiki/Document_Object_Model)

What is org.w3c.dom.Node ?
The Node interface is the primary datatype for the entire Document Object Model. It represents a single node in the document tree. While all objects implementing the Node interface expose methods for dealing with children, not all objects implementing the Node interface may have children. For example, Text nodes may not have children, and adding children to such nodes results in a DOMException being raised. (http://java.sun.com/j2se/1.4.2/docs/api/org/w3c/dom/Node.html)

IDOMNode implements the interfaces IndexedRegion and org.w3c.dom.Node (See Diagram Below)

IDOMModel implement the interface IStructuredModel. Dom Node List constructs IDOMDocument and IDODocument constructs IDOMModel. (See Diagram Below)

IDOMNode can add or append childNode

Make a big picture

TestSchema2.xsd itself is a IDOMNode

To be continue in Bug 243799 - Analysis II .....................

If my concept is wrong, please point it out so I can correct it

Reproduce the Eclipse WTP Bug 243799

I reproduce the Eclipse WTP Bug 243799. First off, I try to reproduce the Bug 243927 but it is not reproduced successfully. From viewing the Bug 243927, a commenter named Valentin points out that the Bug 243799 is similar with Bug 243927. Therefore, I want to try some luck to reproduce the Bug 243799 because they are similar and I do not need to spend more time on analyzing it. Finally, I succeed to reproduce the Bug 243799. Formally, let me introduce the Bug 243799 and my target is going to fix it within two months. Hopefully !

The progress of fixing the bug will be posted in this blog so visited me frequently if you are interested in it.


WTP - Bug 243799

Steps to Reproduce

1.  Have 2 xsd files, TestSchema1.xsd and TestSchema2.xsd, where
TestSchema2.xsd includes TestSchema1.xsd.

2.  Open both xsd files in Eclipse.

3.  Verify that both xsd files validate properly.

4.  Add a new type to TestSchema1.xsd and validate the updated schema.

5.  Switch back to TestSchema2.xsd and attempt to use content assist to user
the new type added in step 4.

6.  Regardless of whether content assist is triggered automatically (e.g. add a
new element or attribute and then enter the type parameter leading content
assist to pop-up with the available types) or manually (via ctrl-space inside
the quotes of the type parameter), the new type entered in step 4 is not
visibile for content assist.

7.  If you manually enter the new type from step 4 however, the validation is
successful.  However, even after this content assist still doesn't make the new
type visible.

8.  If TestSchema2.xsd is closed and then re-opened in Eclipse, content assist
now properly sees the the new type.

9.  Directly related, if you instead remove a type from TestSchema1.xsd in step
4, then the TestSchema2.xsd editor's content assist continues to show the
removed type even though it is no longer visible and validation fails.