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.***
<mailto:[email protected]> www.nuecho.com
<http://www.nuecho.com/> | blog.nuecho.com <http://blog.nuecho.com/>
*Because performance matters.*
_______________________________________________
swtbot-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/swtbot-dev
