[dsdp-tm-dev] Re: Request for API change: systemType icon properties

[Kushal Munir <kmunir@xxxxxxxxxx>]

Hi Martin,

I think I had changed the implementation to use the <property> markup. I
was looking at icons and other attributes as "properties" of the system,
hence the change. However, I do agree with the disadvantages you have
pointed out, especially the fact we have an implicit assumption that all
system types should have an icon. It makes sense to move this attribute
back to the systemType markup.

We also require plugin providers to specify the icon to be shown when the
connection is "live", i.e. connected. In the future, this "iconLive"
property, in my opinion, should not be a required attribute,  but optional.
What would be good is to use some kind of a decorator to differentiate
between connected and non-connected, and any other state the connection may
be in. I think this will require changes to our view label providers.
Anyway, this is something to keep in mind for the future...

We don't need to support falling back on the <property> tag to read the
icon and iconLive attributes.

Cheers,

Kushal Munir
Websphere Development Studio Client for iSeries
IBM Toronto Lab, 8200 Warden Ave., Markham, ON
Phone: (905) 413-3118        Tie-Line: 969-3118
Email: kmunir@xxxxxxxxxx



                                                                           
             "Oberhuber,                                                   
             Martin"                                                       
             <Martin.Oberhuber                                          To 
             @windriver.com>           "David Dykstal"                     
                                       <david_dykstal@xxxxxxxxxx>, David   
             08/24/2006 11:42          McKnight/Toronto/IBM@IBMCA, Kushal  
             AM                        Munir/Toronto/IBM@IBMCA             
                                                                        cc 
                                       "Target Management developer        
                                       discussions"                        
                                       <dsdp-tm-dev@xxxxxxxxxxx>           
                                                                   Subject 
                                       Request for API change: systemType  
                                       icon properties                     
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Dear committers,

I would like to request an API change in the systemTypes
extension point:

In RSE 7 and before, the icon of a systemType was specified
as a String property. For openRSE, this has been changed to
put the icon references into a <property> markup.

The disadvantages of this are, that
 * It is not obvious that icons are required by the code
 * PDE cannot be used to browse for the icon resource
   in the extension point schema editor
 * PDE cannot display the icon in the plugin.xml editor
 * The extension point looks more complex than necessary
 * There is unnecessary extra migration effort from RSE7

I would therefore like to revert to the original structure,
and pass "icon" and "iconLive" in as attributes. I would
like to keep the <property> markup there, in order to
support custom extensions later on.

If you want, the code could also make a fallback to reading
the icon from <property> if it is not available in the "icon"
attribute; but I don't think this is necessary since there is
no released version of this right now.

Any comments on the request?
Can we please vote on this request?

Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm