Hi Ketan,
here is one idea which I think about for a while.
It is not so easy to modify SWTBot's behavior by not changing SWTBot code
itself.
Sometimes I might need a different behavior, like a different matching
strategy. Or I'd like to use a own implementation of SWTBotTreeItem (or
extending the original and just overwriting one method).
The solution would be to use dependency injection and inversion of control. I
haven't worked awful lot with this concept, but it adds a lot of flexibility
without code change of 3rd party components.
This would mean that for example SWTBotTable would be an interface and there
would be a SWTBotTableImpl concrete class. People could change the class used
by SWTBot by setting it with bot.setTableImpl(new MySWTBotTableImpl()) for
instance.
It would also provide a good workaround until a bug has been solved in SWTBot
or so.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
SWTBot-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse
