Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » SWTBot » Wildcards in matchers?
Wildcards in matchers? [message #481427] Thu, 20 August 2009 22:46 Go to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
I see matchers
equalToIgnoringCase(String)
containsString(String)
equalToIgnoringWhiteSpace(String)
endsWith(String)
startsWith(String)

but nothing stated to handle general wildcard descriptions.

Is is expected that any wildcard expansion is provided during your
ICondition.test() implementation?
Re: Wildcards in matchers? [message #481441 is a reply to message #481427] Fri, 21 August 2009 03:28 Go to previous messageGo to next message
Ketan Padegaonkar is currently offline Ketan PadegaonkarFriend
Messages: 873
Registered: July 2009
Senior Member
WidgetMatcherFactory#withRegex() ?

--
Ketan
http://studios.thoughtworks.com/twist | http://twitter.com/ketanpkr


On 21/8/09 04:16, Jay Norwood wrote:
> I see matchers
> equalToIgnoringCase(String)
> containsString(String)
> equalToIgnoringWhiteSpace(String)
> endsWith(String)
> startsWith(String)
>
> but nothing stated to handle general wildcard descriptions.
> Is is expected that any wildcard expansion is provided during your
> ICondition.test() implementation?
>
Re: Wildcards in matchers? [message #481920 is a reply to message #481441] Mon, 24 August 2009 17:24 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
Ketan Padegaonkar wrote:

> WidgetMatcherFactory#withRegex() ?

Yes, that is what I had missed.

I don't see anything referencing withRegex in the workspace.

I could see that String#match() could be used in place of String#equals()
if regex is enabled in several places, and this might be pretty useful.
There is already an ignoreCase flag passed in for some of these. This
could be included with Pattern.CASE_INSENSITIVE in the regex, so it
wouldn't cause the cases to double by adding regex.


SWTBotWorkbenchPart#toolbarButton() getToolTipText().equals(String)

ControlFinder#findShells() shell.getText().equals(String)

WithMnemonic#doMatch() getText(obj).equals(text)

WithText#doMatch() getText(obj).equals(text)

WithTooltip#doMatch() getToolTipText.equals(text)

SWTBotTable#header() column.getText().equals(label)

SWTBotTable#indexOf() tableItem.getText().equals(item)

SWTBotTable#getItem() item.getText().equals(itemText)

SWTBotTree#getItem() item.getText.equals(nodeText)

SWTBotTreeItem#getNodes treeItem.getText().equals(nodeText)

SWTBotTreeItem#getItem() item.getText().equals(nodeText)
Re: Wildcards in matchers? [message #481984 is a reply to message #481920] Tue, 25 August 2009 00:06 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
Jay Norwood wrote:

> I could see that String#match() could be used in place of String#equals()
> if regex is enabled in several places, and this might be pretty useful.
> There is already an ignoreCase flag passed in for some of these. This
> could be included with Pattern.CASE_INSENSITIVE in the regex, so it
> wouldn't cause the cases to double by adding regex.



> SWTBotWorkbenchPart#toolbarButton() getToolTipText().equals(String)

> ControlFinder#findShells() shell.getText().equals(String)

> WithMnemonic#doMatch() getText(obj).equals(text)

> WithText#doMatch() getText(obj).equals(text)

> WithTooltip#doMatch() getToolTipText.equals(text)

> SWTBotTable#header() column.getText().equals(label)

> SWTBotTable#indexOf() tableItem.getText().equals(item)

> SWTBotTable#getItem() item.getText().equals(itemText)

> SWTBotTree#getItem() item.getText.equals(nodeText)

> SWTBotTreeItem#getNodes treeItem.getText().equals(nodeText)

> SWTBotTreeItem#getItem() item.getText().equals(nodeText)


I can see one more useful change:

WithId#doMatch() change value.equals(data) to data.matches(value)

That and the 11 changes above I believe would give regex capability to all
the Strings used by SWTBot.java.

That may be 300 functions, so seems like not a good idea to be expanding
parameter lists at that level.

Maybe instead Rx(String) could be passed as a decorated String in all the
SWTBot calls, and then the Rx decorated parameters would be handled at the
lowest level in only the 12 functions above.
Re: Wildcards in matchers? [message #481997 is a reply to message #481920] Tue, 25 August 2009 04:50 Go to previous messageGo to next message
Ketan Padegaonkar is currently offline Ketan PadegaonkarFriend
Messages: 873
Registered: July 2009
Senior Member
On 24/08/09 10:54 PM, Jay Norwood wrote:
> Ketan Padegaonkar wrote:
>
>> WidgetMatcherFactory#withRegex() ?
>
> Yes, that is what I had missed.
> I don't see anything referencing withRegex in the workspace.
> I could see that String#match() could be used in place of
> String#equals() if regex is enabled in several places, and this might be
> pretty useful. There is already an ignoreCase flag passed in for some of
> these. This could be included with Pattern.CASE_INSENSITIVE in the
> regex, so it wouldn't cause the cases to double by adding regex.

Most people are happy with string equals match. For folks who do need
regex support (and there are valid reasons for this) there's always
overloaded methods that take in a matcher at most places.

I'd prefer to keep the code simple and an 'if' check all over the place
to check for a regex does not seem like a particularly good solution.

So while I like the idea of enabling a global regex support, I'm going
to wait until more folks ask for it.

--
Ketan
http://studios.thoughtworks.com/twist | http://twitter.com/ketanpkr
Re: Wildcards in matchers? [message #481998 is a reply to message #481984] Tue, 25 August 2009 04:56 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
Jay Norwood wrote:

> Maybe instead Rx(String) could be passed as a decorated String in all the
> SWTBot calls, and then the Rx decorated parameters would be handled at the
> lowest level in only the 12 functions above.


oops can't do that because String is final.
Re: Wildcards in matchers? [message #482001 is a reply to message #481997] Tue, 25 August 2009 05:41 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
Ketan Padegaonkar wrote:

> Most people are happy with string equals match. For folks who do need
> regex support (and there are valid reasons for this) there's always
> overloaded methods that take in a matcher at most places.

> I'd prefer to keep the code simple and an 'if' check all over the place
> to check for a regex does not seem like a particularly good solution.

> So while I like the idea of enabling a global regex support, I'm going
> to wait until more folks ask for it.

I was thinking that those bottom 12 functions could be changed to handle a
Regex or String, and then the top level 300 or so functions in SWTBot
would be unchanged, and the user could decide to use, for example,

bot.tree().select("MyTreeNodeNameThatMightHaveSomeLongSuffixIDontWantToType ").click();

or

bot.tree().select(Rx("My.*")).click();

But String is final, so that didn't work.

I suppose if all the top level String parameters were changed to Object
then that could be made to work, but too many functions to change to try
it tonight.
Re: Wildcards in matchers? [message #482528 is a reply to message #481984] Wed, 26 August 2009 21:58 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
Registered: July 2009
Senior Member
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 #482553 is a reply to message #482528] Thu, 27 August 2009 03:31 Go to previous messageGo to next message
Ketan Padegaonkar is currently offline Ketan PadegaonkarFriend
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 Go to previous messageGo to next message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
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 #482566 is a reply to message #482565] Thu, 27 August 2009 05:23 Go to previous messageGo to next message
Ketan Padegaonkar is currently offline Ketan PadegaonkarFriend
Messages: 873
Registered: July 2009
Senior Member
On 27/08/09 10:41 AM, Jay Norwood wrote:
> 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.

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.

--
Ketan
http://studios.thoughtworks.com/twist | http://twitter.com/ketanpkr
Re: Wildcards in matchers? [message #482576 is a reply to message #482566] Thu, 27 August 2009 06:49 Go to previous message
Jay Norwood is currently offline Jay NorwoodFriend
Messages: 112
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.
Previous Topic:drag-and-drop operations with SWTBot?
Next Topic:Bugfixing of local swtbot plugins
Goto Forum:
  


Current Time: Thu Nov 27 18:58:38 GMT 2014

Powered by FUDForum. Page generated in 0.04113 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software