[kepler-dev] Kepler specific Director and ComponentEntity classes and _addIcon()

Christopher Brooks cxh at eecs.berkeley.edu
Mon Apr 17 21:21:09 PDT 2006

Hi Edward,

I'm looking at folding in the Kepler copies of Director
and ComponentEntity.  The reason to fold these in is
to avoid code duplication and reduce maintenance.

Both of these classes have _addIcon methods like:

    private void _addIcon() {

      //simple Icon:
      _attachText("_iconDescription", "<svg>\n"
                  + "<rect x=\"-30\" y=\"-20\" width=\"60\" "
                  + "height=\"40\" style=\"fill:white\"/>\n"
                  + "<polygon points=\"-20,-10 20,0 -20,10\" "
                  + "style=\"fill:blue\"/>\n" + "</svg>\n");

      try {
      } catch (Exception ex) {
        //ignore exceptions - they just mean that the
        //default icon will be used, as defined above

In this case,
is a Kepler static method that takes a NamedObj as an argument
and adds an SVG icon.  So, we need some way for Kepler
to override the icons without subclassing Director.  We
can't subclass Director here because SDFDirector etc all
extend Director and they would not extend our new class that
had the custom Kepler icons.

I could hack some Kepler specific hack that used reflection to look
for a specific class that added the icon, but I think it would be
better to add methods that named a class that on which we invoked a
method that would add the Icon.

Unfortunately, it looks like this would go in NamedObj and thus would
be present for all NamedObjs.  I think it would be better for Director
and ComponentEntity to have a setter that sets a class on which we can
call an addIcon().  Yes, this is a little bit of code duplication, but
it is not horrible.  Perhaps we could have Director and
ComponentEntity implement a IconableFactory(?) interface that just has
the setIconable method.

Director and ComponentEntity would both get
    setIconable(Iconable iconable) {
        _iconable = iconable
    private static Iconable _iconable;

    private void _addIcon() {
        if (_iconable != null) {
            try {
	    } catch (Exception ex) {
                //ignore exceptions - they just mean that the
                //default icon will be used, as defined above

ComponentEntityConfig would implement Iconable and have
    public static addIcon(NamedObj) {
The KeplerInitiailizer would call setIconable() for
Director and ComponentEntity and set it to ComponentEntityConfig.

Whattya think?  Do you have any ideas?

Director and ComponentEntity should not really have icon specific code
in them, but they already have _attachText() calls.  


More information about the Kepler-dev mailing list