| [papyrus-rt-dev] Nattable property table vs JFace tree viewer in UMLRT perperty view |
Hi Team,
While ago I raised a bug.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=513384
To make it short, I wasn't really sure if we needed to use Nattable property table in UML-RT as it seem a bit heavy for the usage in the property view.
I understand that the word "heavy" does not apply if the features supported by nattable benefit users who are using UML-RT.
To be honest I wasn't even quite sure all the supported features by nattable and how much they are used in the properties tab specifically.
So my main reasoning behind the suggestion was the following:
1. We can reuse existing (InheritableMultiReference, MultiReferenceEditor) code to support UML-RT tables with small modification to the existing code.
This means that we can support inheritance and its control buttons for free.
It didn't seem right to have two different class doing the same thing which was already a case for the control button editor in UML-RT nattable. I was keen on getting ride of it.
2. I wasn't sure if it is possible to provide an image for the cell. I found out that it is possible for the header cells but not with regular cells.
There are more comments on this bug so take a look at them if you need some background on this issue.
I think we should make a conclusion as soon as possible so we can move on and work on the bugs that are blocked by this bug.
My suggestion is that we leave the nattable as it is with the condition that the regular cell image can be supported separately.
We can then find a way to refactor some classes to minimize duplication between nattable editor and regular multi reference editor that uses JFace viewer.
Their table representations are different but I think their underlying machines to process the request and the list button editors could share some common code base.
Christian is working on the bug related to the trigger table in UML-RT and hope that he can shed us some lights on this.
I am ok with either way as long as we can get to the conclusion quickly and start working on it if we have to.
Please let me know if you have any comments regarding this discussion.
Thanks.
Regards,
Young-Soo Roh
Zeligsoft(2009) Ltd