Community
Participate
Working Groups
See attached TestCase
Created attachment 177830 [details] Test case
As described in forum http://www.eclipse.org/forums/index.php/m/674212/#msg_674212 here a proposal for a solution to this ticket. -- A ui to widget mapping - from an architectural point of view - should not just be measured on how strict or straight-forward (class names...) it is but how and where it is extendible, where it is not, and how flexible it is. In short: Good design is simple, flexible and extensible in its main aspects BUT may be strict, closed and final in its side aspects. May I point to a very similar area of architectural design pattern regarding ui mapping in swing. Swing has as it's core concept the separation of widgets (JButton, JTextField) and their ui (ButtonUI, TextFieldUI). A look- and-feel (or theme) is created by creating a ui layer for example SynthButtonUI, SynthTextFieldUI etc. The connecting glue between widget and ui is JComponent.getUIClassID(); public String getUIClassID() { return uiClassID; } Every subclass of JComponent may overwrite the UIClassID property (for example ComponentUI, ButtonUI, TextFieldUI, etc.) Also in swing it is not recommended to subclass swing widgets. However sometimes it is done and necessary to work around bugs and features coming too late to the project. The way swing maps widgets to ui is simple, flexible and extensible. As it is not realistic to extend SWT's Widget with a property "getUIClassID" we may use the SWT idea of extension. "Adapters". RWT may add the IUIClassAdapter to their widget implementation. public interface IUIClassAdapter{ String getUIClassID(); } The rwt ui mapper may simply call String uiClass=((IUIClassAdapter)aWidget.getAdapter(IUIClassAdapter.class)).getUIClassID(); Whether or not a swt widget is a subclass does compromise ui mapping. There is no drawback to todays solution. That way is more flexible, backward compatible to JRE1.4 and eclipse 3.4 and reduces swt design impacts on rwt ui mapping. From a design and architecture point of view a "better" solution.
I have a easy solution for this problem. It would help us a lot, if this patch would be approved and committed.
Created attachment 205799 [details] Test case Makes the Patch from Ralf obsolete.
Created attachment 205800 [details] Proposed solution
Thanks for the patches, Stephan. I applied them to CVS with some changes. In particular, I removed the fallback to the simple class name, which I believe was obsolete.
Thanks for the fix.