[swtbot-dev] Bug 282408

[Pascal Gelinas <pascal.gelinas@xxxxxxxxxx>]

I'm coming back to this one since GEF (which I started to test using swtbot4gef) makes a heavy use of CellEditor to enable edition of values inside a GraphicalEditor. I was thinking about a class hierarchy like:
AbstractCellEditor<T extends Widget> {
   T widget
   // some useful methods, such as applyEdition, cancelEdition
}

TextCellEditor extends AbstractCellEditor<Text> {
   // some specific methods, such as typeText(). Most of those method would be transmogrifier.
}

ComboCellEditor extends AbstractCellEditor<CCombo> {
}

and other concrete cell editor (see the class hierarchy of org.eclipse.jface.viewers.CellEditor).

Those class would present a functional view of a cell editor, i.e. how a user uses a cell editor normally. I don't think usual mock-up methods would work here (such as #setText(String)) since a cell editor is a JFace component that adds listeners to the widget it is attached on,

The problem is see right now is how to find those cell editors... would something like:
SWTBot class:
public TextCellEditor textCellEditor(Text text)
{
   return new TextCellEditor(text);
}
public AbstractCellEditor<T extends Widget> cellEditor(Widget widget)
{
   if (widget instanceof Text)
   {
       return textCellEditor((Text) widget);
   }
}

or
SWTBotText class:
public TextCellEditor textCellEditor()
{
   return new TextCellEditor(widget);
}

be appropriate? This has the inconvenient of creating an adapter of a cell editor where it might not be one. It has the advantage of being really easy to implement.

Or let the bot do some obscure search:
SWTBot class:
public TextCellEditor textCellEditor()
{
   Text text = text().widget;
   Listener[] listeners = text.getListeners(SWT.Modify);
   for (Listener listener : listeners)
   {
       Class<? extends Listener> clazz = listener.getClass();
       // The listeners are declared as anonymous classes inside different methods (createControl and getModifyListener)
       Method enclosingMethod = clazz.getEnclosingMethod();
       if (enclosingMethod == null)
       {
           continue;
       }
       Class<?> declaringClass = enclosingMethod.getDeclaringClass();
       if (declaringClass.getName().equals(TextCellEditor.class))
       {
           return new TextCellEditor(text);
       }
   }
   throw WidgetNotFoundException("Could not find cell editor");
}

This approach has the major disadvantage of being bound to the implementation of the cell editor. It has the advantage of creating adapters only for real cell editors.

Personally, I would prefer the first approach since it is easier, less code to write and is not bound to a specific implementation. Creating an adapter for fake cell editor is not a problem in itself, since the adapter is only an abstraction of user actions and all of its method works even if the widget is not a cell editor.

What do you think? I'm going to create the class hierarchy right away but I'll wait for feedback for the search.

--
Pascal Gélinas | Software Developer
Nu Echo Inc.
www.nuecho.com | blog.nuecho.com

Because performance matters.