On 7/1/05, Mike Williams <[EMAIL PROTECTED]> wrote: > When I introduced the PatternMatcher stuff recently, I used the same > kind of "reflection" trick we use for locators, commands, etc; > PatternMatcher tried to map a prefix like "regexp" to a function-name > like "RegexpMatchStrategy". > > I realised tonight that it's simpler to just build the registry > directly, rather than rely on these naming conventions. What it means > is that rather than declaring > > PatternMatcher.RegexpMatchStrategy = function(pattern) ... > > now it says > > PatternMatcher.strategies.regexp = function(pattern) ... > > so we can index directly into the "strategies" array using the pattern > prefix. > > I wonder if we could use the same approach for locators and > option-specifiers; what do you think? Perhaps even for commands and > assertions, too?? > > I guess I'm talking about rethinking Selenium's extension API, and if > we're rethinking it, we should probably be careful to introduce some > consistency. Currently we have > > Selenium.prototype.doMyCommand = ... > Selenium.prototype.assertMyCondition = ... > PageBot.prototype.locateByMyCriteria = ... > PatternMatcher.strategies.myPatternType = ... > OptionLocatorFactory.prototype.OptionLocatorByMyCriteria = ... > > How about something like: > > Selenium.commands.myCommand = ... > Selenium.asserts.myCondition = ... > Selenium.elementLocators.myCriteria = ... > Selenium.patternMatchers.myPatternType = ... > Selenium.optionMatchers.myCriteria = ...
I think you're right - this mechanism is a bit clearer for cases where we don't need subclasses to override behaviour. I'm not so sure how we'd do it for locators where we have different implementations for different BrowserBot subclasses - thoughts? ciao Daz _______________________________________________ Selenium-devel mailing list Selenium-devel@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
