[
http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19641#action_19641
]
Jarmo Pertman commented on WTR-437:
-----------------------------------
Bret: Thanks for the Ruby Way analogy :)
Jari: Don't even try to bring here this performance "penalty". I wouldn't even
consider this as a penalty if the numbers are like they are plus majority of
the time with testing web applications is spent for waiting after application
under test. If we're going to bring this kind of reasons in here then why not
try to implement Watir in pure C to gain performance boost (kiddin')? :)
This improvement is not done in 1 step due to this backwards incompatibility
problem. I still think that it would be more clear if there would be only one
syntax and no dealing with arrays.
def text_field(args*)
args = {args.first => args.last} if args.size == 2
end
would become
def text_field(args)
end
It's not a huge improvement, but think of it as a growing technical debt -
you'll have to support both of these syntaxes for every new part you code and
everyone else codes. Even if you're going to extend Watir's classes then you'd
have to put these if-statements everywhere. It just looks bad.
Ethan: How often do you think that regular users will use ie or ole_object? I'm
quite sure that it happens almost never. And if you're talking about xpath,
then:
1) I wouldn't recommend it to use at all because it just looks ugly and makes
your tests look uglier. Just add an 'id' to the html element or make the
developers to add those.
2) If you make these xpath-s to be very specific, then they will probably break
if html changes.
3) If you make these xpath-s to be too loose, then they will probably break if
html changes.
4) Searching by xpath is slower.
5) If you think of it then xpath is an element attribute as a location of the
element. It's as much of an attribute as a 'text' is for example. I don't see
any problems with using xpath attribute with hash.
To be honest, i have never in my Watir 3+ years used xpath for locating element.
Jarmo
> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
> Key: WTR-437
> URL: http://jira.openqa.org/browse/WTR-437
> Project: Watir
> Issue Type: New Feature
> Components: Other
> Affects Versions: 2.0
> Environment: any
> Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir
> websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development
