For Selenium automation we pervasively added support for Locatable widgets, basically setting explicit, hierarchical IDs on all of the widgets to be able to perform repeatable tests. This adds complexity to the code, as well as some overhead with a bunch of string generation. We have ditched Selenium in favor of Sahi, and we are not using the locators. Although folks are still trying to use Locatables, I don't think it's been fully maintained and I'm sure running with locators on would probably not work well at this point. Although it still can be useful at times for debugging, the weight of keeping it in is probably not worthwhile. It's not trivial, it will touch a ton of stuff, and there are actually some built in hooks that enhance destroy logic. But overall I think it's a burden, and increases code complexity, making it harder for us, and potentially contributors.
Additional commentary from irc with jshaughn and mtho11: we thought we were golden given that SmartGWT provided selenium integration out of box but things never worked well for whatever reasons the selenium functions for determining when a widget was present/visible/enabled never seems to work quite right and even with repeatable 'locator ids' it was still tedious to write testws those aids all had to be assembled in the test code etc so QA started looking for alternatives and found Sahi which does not actually use the locators, it uses a different mechanism for identifying widgets (i guess, I'm not familiar) I think it's positional or something like that Anyway, now we have all of this locator id stuff in place, and a bunch of 'Locatable' subclasses for smartgwt widgets. we also have a tone of destroy() methods implemented to avoids things like ID clashes. Meaning, proactive destruction as opposed to letting SmartGWT clean up the DOM at its leisure it's actually the destroy() stuff that could be the delicate point I'm not sure whether we should keep that stuff in there (and there is some support down in the Locatable subclasses) or try to take it out it's not really, so my thought would be to leave it in we may just have to create a couple of new Subclasses to replace the Locatables that have destroy support. Even though the destroy calls may not be necessary, proactive cleanup may not be a bad thing from a regression perspective I'd say leaving it as-is would be preferable
*** Bug 786217 has been marked as a duplicate of this bug. ***
Jay already removed the selenium stuff this is old and no longer relevant.