|
|
|
|
|
|
|
|
| Re: Wildcards in matchers? [message #482553 is a reply to message #482528] |
Thu, 27 August 2009 03:31   |
 Ketan Padegaonkar
Messages: 873
Registered: July 2009 |
Senior Member |
|
|
SWTBot provides enough APIs for most of the users and enough hooks for
customization for the rest. I'd not be accepting this patch since nobody
else has asked for it, and you're the only person needing it, atleast
for now.
Also code littered with if statements seems completely wrong.
--
Ketan
http://studios.thoughtworks.com/twist | http://twitter.com/ketanpkr
On 27/08/09 3:28 AM, Jay Norwood wrote:
> I modified the 12 or so locations in swtbot code that use String#equals
> to instead use String#matches if SWTBotPreferences.REGEX_ENABLED is set.
> This provides a user option to use regular expressions parameters in
> most calls that currently use String parameters in the upper level
> SWTBot methods.
> My tests ran 75 seconds before adding the regex code, 77 with added but
> disabled, 80 seconds with added and enabled, so it doesn't seem to be
> causing much overhead for my particular tests.
>
> The only changes required were in org.eclipse.swtbot.swt.finder, plus a
> single change in
> org.eclipse.swtbot.eclipse.finder.widgets.SWTBotWorkBenchPar t.
> The changes required are tiny. For example, the three lines added below
> in the WithId#doMatch add selectable regex capability for any method
> that uses withId(String).
>
>
>
> protected boolean doMatch(final Object obj) {
> String data = UIThreadRunnable.syncExec(new Result<String>() {
> public String run() {
> return (String) ((Widget) obj).getData(key);
> }
> });
> if (SWTBotPreferences.REGEX_ENABLED == 1){
> return data.matches(value);
> }
> return value.equals(data);
> }
>
> ------------
> and the three lines added to WithMnemonic#doMatch below add selectable
> regex capability for any method that uses WithMnemonic(String).
>
> protected boolean doMatch(Object obj) {
> try {
> boolean result = false;
> if (SWTBotPreferences.REGEX_ENABLED == 1){
> result = getText(obj).matches(text);
> }
> else if (ignoreCase)
> result = getText(obj).equalsIgnoreCase(text);
> else
> result = getText(obj).equals(text);
> return result;
> } catch (Exception e) {
> // do nothing
> }
> return false;
> }
>
>
> ----------
> I'm going to propose this as a solution for enabling regular expressions
> in the several hundred parameters where only simple String compare is
> currently available, and will zip up the few sources and attach it to
> the proposal. All additions for this can be located by searching for
> REGEX_ENABLED.
>
|
|
|
| Re: Wildcards in matchers? [message #482565 is a reply to message #482553] |
Thu, 27 August 2009 05:11 |
Jay Norwood
Messages: 155
Registered: July 2009 |
Senior Member |
|
|
Ketan Padegaonkar wrote:
> SWTBot provides enough APIs for most of the users and enough hooks for
> customization for the rest. I'd not be accepting this patch since nobody
> else has asked for it, and you're the only person needing it, atleast
> for now.
That's surprising, because I was trying to introduce it to someone else
and one of the first questions they asked me was if they could use
wildcards in the strings.
> Also code littered with if statements seems completely wrong.
I proposed alternatives of changing all the String parameters to Object so
that we could use Regex objects or String objects, but that affects maybe
300 methods.
You could add a flag to the parameters, similar to what you've already
done with ignorecase in a few instances, but then that will eventually
need an ugly IF statement, as you already have in the lower level code
that finally handles that flag.
You could add another suffix to all your top level function names, as you
seem to like, buttonInGroupWithLabelUsingRegex(...), but that would again
require doubling the 300 methods in order to handle it consistently.
Why don't you give the example of how you would handle it. What I've
proposed is just a simple if statement in 12 or so low level functions and
a global switch that then enables consistent availability of regex for 300
or so upper level functions with the set of a single global preference.
|
|
|
|
| Re: Wildcards in matchers? [message #482576 is a reply to message #482566] |
Thu, 27 August 2009 06:49 |
Jay Norwood
Messages: 155
Registered: July 2009 |
Senior Member |
|
|
Ketan Padegaonkar wrote:
> Aye! Let me think over it for a while, and I'll get back to you. Are
> there any specific places where you'd like to see regex support ? I can
> image this being the case in maybe trees or so.
I'd prefer regex to be available consistently for String parameters if I
turn on the REGEX_ENABLED switch. There were several places where a
matcher, isEqual, was used rather than the String equals, and my submitted
code didn't handle those few cases, but I'd like those to be handled as
well.
I think if there were some editing mode that permitted you to capture the
info from selected widgets, then it would be less of an issue.
In particular, pop-up text, group box names, and WithId strings can all be
pretty tedious to enter and pretty long to look at in your code.
|
|
|
Powered by
FUDForum. Page generated in 0.03662 seconds
] 
Search
Help
Register
Login
Home
