This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 84157 - Update the visual appearance of elements in and complex types in Design View
Summary: Update the visual appearance of elements in and complex types in Design View
Status: VERIFIED FIXED
Alias: None
Product: xml
Classification: Unclassified
Component: Schema Tools (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Girish Balachandran
URL: http://xdesign-tools.czech.sun.com/us...
Keywords: UI
Depends on: 84755
Blocks:
  Show dependency tree
 
Reported: 2006-09-04 17:36 UTC by Jiri Kopsa
Modified: 2006-10-16 21:55 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
DV showing a complex type and one element which has that type (98.56 KB, image/jpeg)
2006-09-10 16:13 UTC, Chris Webster
Details
View with inheritance from other files (120.61 KB, image/jpeg)
2006-09-10 16:42 UTC, Chris Webster
Details
New implemented ABE view (78.66 KB, application/octet-stream)
2006-09-15 01:20 UTC, Girish Balachandran
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Kopsa 2006-09-04 17:36:38 UTC
Use the colour distinction in the Design View to distinguish between inherited
and locally defined elements and attributes instead of the current distinction
between complex types and elements (which is not being understood).

For more information, see the usability study report:
http://xdesign-tools.czech.sun.com/usability/jse/jse9-coke-endToEnd/report.html#AIColorsInheritedVsLocal
Comment 2 Chris Webster 2006-09-10 16:13:46 UTC
Created attachment 33739 [details]
DV showing a complex type and one element which has that type
Comment 3 Chris Webster 2006-09-10 16:41:13 UTC
I have added an image that shows a single element which is an instance of aType
complex type. I think the recommendation here is to have the complexType and
it's elements be the same color as the "a" element. The inhertied elements from
the complexType would be displayed as they are now. 

There is an additional image which displays read-only, type is coming from
another file. These elements and attributes are grey and also have the include
badge. However, in this image notice that the subattribute element is displayed
normally even though it is inherited. 

To summarize, here is what I think should be done:

1. Display complexTypes and their children using the same color (basically the
coloring schema should be same between complexType and elements if children are
inherited ...)

2. inherited attributes should be displayed in the inherited color (blue). 




Comment 4 Chris Webster 2006-09-10 16:42:50 UTC
Created attachment 33740 [details]
View with inheritance from other files
Comment 5 Girish Balachandran 2006-09-14 22:28:52 UTC
Partially fixed this bug. There is an NPE that has to be fixed so I am not
integrating yet.
Comment 6 Jiri Kopsa 2006-09-15 01:01:34 UTC
As I'm not sure that it follows the suggestions in the specifications, I wanted
to play a bit with that. But I cannot see in the recent build. I have (Build
200609120000, Ent. Pack 20060914).

Maybe you guys have a better build for me. ... oh now I can see the comment on
'not integrating yet'. When is it to come?
Comment 7 Girish Balachandran 2006-09-15 01:17:29 UTC
I implemented what Chris mentioned in this bug report that complextypes will
same background color as elements. And also made a visual distinction for attrs
inherited from complextypes. I have attached the image for PO. Could you please
verify what you see with the attached image?
Comment 8 Girish Balachandran 2006-09-15 01:20:38 UTC
Created attachment 33979 [details]
New implemented ABE view
Comment 9 Girish Balachandran 2006-09-15 03:08:27 UTC
Fixed on 9/14
Comment 10 Jiri Kopsa 2006-09-19 10:43:59 UTC
I've checked, everything looks fine. Great job!

Only a couple of comments:
* If an attribute ref points to one in a different file, it should be gray, but
it's not.
* Also I can see that XSD import icon has been added to imported nodes. Perhaps
it may get too overwhelming, maybe just one on the root referring node would be
enough. I think that gray colour and tooltip provides enough information.
* As we needed to pull multiplicity annotations out from the TAB object, let's
make them also gray.
Comment 11 Jiri Kopsa 2006-09-21 09:09:18 UTC
I'm reopening this to get the rest fixed (per comments in previous post). Also
lowering the priority as the most significant part of this has been fixed already.
Comment 12 Girish Balachandran 2006-09-21 10:03:16 UTC
Already integrated. Pl check the latest build.
Comment 13 Jiri Kopsa 2006-09-21 12:55:58 UTC
There is still something:

* This has not been fixed yet: If an attribute ref points to one in a different
file, it should be gray (the background color), but it's not.

* I can see you the import icon have been removed. I thought we could leave one
icon on the root referring node. Does it make sense?
Comment 14 Girish Balachandran 2006-09-21 16:55:33 UTC
* I can see you the import icon have been removed. I thought we could leave one
icon on the root referring node. Does it make sense?
>> This makes UI logic complex and I would not like to do this for this release.
May be an REF for later.

* This has not been fixed yet: If an attribute ref points to one in a different
file, it should be gray (the background color), but it's not.

>> I do not agree with the ref being shown as a read-only if it comes from a
different file. Even though the referent comes from other file, the reference
itself is defined locally to the file. User should be able to change all the
properties (except name). The definition section will soon have way to change a
reference to point to some other artifact. If we show grayed out that means that
user will not be able to change that component there. So, I would suggest to let
the references be shown as a shared UI rather graying out and making read-only.
Comment 15 Chris Webster 2006-09-21 17:18:41 UTC
I agree with both points mentioned by girish. The reference itself can be
modified locally such as changing the cardinality but what is refers to cannot.
The icon change will have to be done next time. 
Comment 16 Jiri Kopsa 2006-09-21 22:39:36 UTC
Ok, I agree.

Thanks for clearing this out to me.

Perhaps, we should do something more in this area (as the type of the referred
attribute cannot be changed).
Comment 17 Jiri Kopsa 2006-09-28 13:03:03 UTC
Verified.