Community
Participate
Working Groups
Created attachment 111032 [details] Outline1.png Build ID: Eclipse: I20080617-2000, WTP: 20080616152118 The problem occurs when [Group items logically] button of the toolbar of Outline view is clicked. The source doesn't synchronize with the node of Outline view. Some examples are shown below. Pattern 1: 1. Open the DTD file of the following source. <!ELEMENT NewElement1 EMPTY> 2. Types so that the source become as follows. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute CDATA #IMPLIED> --> The node of Outline view becomes like the left of Outline1.png. 3. Save the editor. Open the DTD file again. --> The node of Outline view becomes like the right of Outline1.png. The attribute under the Attributes node doesn't exist. Pattern 2: 1. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute CDATA #IMPLIED> 2. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 ChangeAttr CDATA #IMPLIED> --> The left of Outline2.png. 3. Save the editor. Open the DTD file again. --> The right of Outline2.png. The attribute under the Attributes node doesn't change. Pattern 3: 1. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute1 CDATA #IMPLIED> <!ATTLIST NewElement1 NewAttribute2 CDATA #IMPLIED> 2. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute1 CDATA #IMPLIED> --> The left of Outline3.png. 3. Save the editor. Open the DTD file again. --> The right of Outline3.png. The NewAttribute2 attribute under the NewElement1 element is not deleted. Pattern 4: The problem occurs by a syntax not validate as follows. 1. <!ELEMENT NewElement1 EMPTY> <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute1 CDATA #IMPLIED> 2. <!ELEMENT NewElement1 EMPTY> <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 ChangeAttr CDATA #IMPLIED> --> The left of Outline4.png. 3. Save the editor. Open the DTD file again. --> The right of Outline4.png. The attribute under the Attributes node doesn't change. Moreover, the NewAttribute1 attribute under the second the NewElement1 element is not changed. The problem occurs when not clicking on [Group items logically] button. Some examples are shown below. Pattern 5: 1. <!ELEMENT NewElement1 EMPTY> 2. Delete all content of the source. --> The left of Outline5.png. 3. Save the editor. Open the DTD file again. --> The right of Outline5.png. The NewElement1 element exists. Pattern 6: Problem of Bug 157430. More information: I attached sample patch. The model of the Element and the Attribute doesn't have the relation between parent and child. The implementation of DTDTreeContentProvider#getChildren produces the relation. Other methods are fixed based on the implementation. However, the patch has the following problem. I was not able to resolve this problem. 1. <!ELEMENT NewElement1 EMPTY> <!ATTLIST NewElement1 NewAttribute CDATA #IMPLIED> 2. <!ELEMENT NewElement1 EMPTY> <!ATTLIST ChangeElement NewAttribute CDATA #IMPLIED> --> The left of Problem1.png. 3. Save the editor. Open the DTD file again. --> The right of Problem1.png. The NewAttribute attribute exists under the NewElement1 element.
Created attachment 111033 [details] Outline2.png
Created attachment 111034 [details] Outline3.png
Created attachment 111035 [details] Outline4.png
Created attachment 111036 [details] Outline5.png
Created attachment 111037 [details] Problem1.png
Created attachment 111038 [details] sample patch
targeting for 3.1m7
Due to some other underlying issues discovered in bug 245216 I think it's best to try to address this early in 3.2M1.
Nick or Nitin can you guys take a look at this patch. I know that there are some issues that Nitin and I discussed about how the DTD document model is implemented with the SSE, so I had a not that we needed to review this. I'd like to try and address this during 3.2M3 or 3.2M4.
(In reply to comment #9) > Nick or Nitin can you guys take a look at this patch. I know that there are > some issues that Nitin and I discussed about how the DTD document model is > implemented with the SSE, so I had a not that we needed to review this. I'd > like to try and address this during 3.2M3 or 3.2M4. In nodesRemoved(), I'm curious about the outer loop for (int i = 0; i < count;i++). This looks like it would just cause the same items to be removed from the viewer (count) times. Also, in the if block following, we'd remove the same objects from the viewer again. Is that step necessary? Will we see a regression if the code from Bug 111100 is removed?
(In reply to comment #10) > (In reply to comment #9) > > Nick or Nitin can you guys take a look at this patch. I know that there are > > some issues that Nitin and I discussed about how the DTD document model is > > implemented with the SSE, so I had a not that we needed to review this. I'd > > like to try and address this during 3.2M3 or 3.2M4. > > In nodesRemoved(), I'm curious about the outer loop for (int i = 0; i < > count;i++). This looks like it would just cause the same items to be removed > from the viewer (count) times. Also, in the if block following, we'd remove the > same objects from the viewer again. Is that step necessary? > > Will we see a regression if the code from Bug 111100 is removed? Any opinions?
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Nick or Nitin can you guys take a look at this patch. I know that there are > > > some issues that Nitin and I discussed about how the DTD document model is > > > implemented with the SSE, so I had a not that we needed to review this. I'd > > > like to try and address this during 3.2M3 or 3.2M4. > > > > In nodesRemoved(), I'm curious about the outer loop for (int i = 0; i < > > count;i++). This looks like it would just cause the same items to be removed > > from the viewer (count) times. Also, in the if block following, we'd remove the > > same objects from the viewer again. Is that step necessary? > > > > Will we see a regression if the code from Bug 111100 is removed? > > Any opinions? The only way to find out for sure, is to setup a Unit test for this particular bug and patch.
Because I was in DTDTreeContentProvider to fix Bug 157430 Nick suggested I fix these problems while I was at it. I have submitted a patch to Bug 157430 that fixes ALL of the problems described in both of these bugs. This includes the problem described in the description of this bug that the "sample patch" provided by Naoki Akiyama does not fix. The work I did for the patch in Bug 157430 is very loosely based off the patch provided here but I did a lot of reorganizing to make the whole class flow better and eliminate duplicate code. I would say this bug can now either be duped against the other or set to depends on. I leave that up to the owner.
Ian's patch for Bug 157430 addresses all of these concerns. We'll pursue a fix from there. *** This bug has been marked as a duplicate of bug 157430 ***
