IDL checked in
Simon Stewart
I've just checked in the first version of the proposed IDL for the
browser automation standard[1]. It's certainly not complete, but I
think it gives us something to have an ongoing conversation about.
Things that I am aware are missing:
* Any exceptions being thrown from methods
* Nothing that maps to the advanced user interactions API
* No mechanism for detecting the capabilities supported by a browser
* Anything equating to Command and Response
Those last two are fairly major omissions since they provide a
mechanism for actually creating something like the remote webdriver.
We'll fix that soon. Comments are welcome.
The next step will be to start hanging some documentation off this
(extremely bare) text.
Cheers,
Simon
[1] http://code.google.com/p/selenium/source/browse/wiki/standard/webdriver.idl
Jim Evans
--Jim
Simon Stewart
Simon
> --
> You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
> To post to this group, send email to selenium-...@googlegroups.com.
> To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
>
David Burns
David Burns
URL: http://www.theautomatedtester.co.uk/
Simon Stewart
Simon
Daniel Wagner-Hall
* I'm not sure about specifying value given that it's a shortcut for
getAttribute("value")
* Could TimeUnit be more strongly typed?
* Cookie handling seems strangely lumped together with meta driver
management - maybe we should pull out a Cookies or CookieJar interface
* TargetLocator.frame(String nameOrId); - nameOrId: Ick.
David Burns
Jim Evans
out here on the list, as per Simon's suggestion.
To that end, my initial thoughts are as follows:
I wholeheartedly, and enthusiastically support proposing a set of
interfaces as a standard. Our job as creators of tools to enable
testers create automated tests can only be made easier when we can
point to a standard for browser vendors to adhere to. In doing so,
however, we are opening the API up to a lot of scrutiny to a much
larger audience than we have previously. How willing are we to adjust
our IDL to the suggestions of the larger "web standards" community?
Are we willing to break the existing API implementation, and by
extension existing user code bound to the current version of the API,
to conform to the IDL?
Regarding the Manage and Navigate interfaces, I know these are the
names of the methods in the Java implementation, but shouldn't the
interface name be a noun? Looking through the other web standard IDLs,
I don't see any interfaces with names that are verbs. Suggestions:
OptionsManager and Navigator (though Navigator may be confusing, since
it conflicts with an existing HTML5 interface name).
There is currently no IDL for RenderedWebElement, et al. I realize
that the user interaction API isn't represented yet; I look forward to
it being so, and some of the methods on these additional interfaces
are subsumed by that API. I know that not every browser that we
support renders content (I'm looking at you HtmlUnit). Nevertheless,
it seems to me that we could benefit from formalizing and
standardizing the additional interfaces. Perhaps some of this goes
back to the discussion of what should really be represented in the
WebElement interface and whether it makes sense to reorganize the
RenderedWebElement and Locatable interfaces.
I can see now through the formalization of the IDL that several things
that are currently methods in the .NET bindings should, in fact, be
read-only properties. I need to figure out whether to make the
changes, and if so, how to properly communicate these breaking changes
to the user base.
--Jim
On Mar 7, 8:14 am, David Burns <david.bu...@theautomatedtester.co.uk>
wrote:
>
> Where did you put your code review comments? I can't see any by the source.
> I ask because I have been expecting to see something from Jim as he had
> thoughts too.
>
> David Burns
> URL:http://www.theautomatedtester.co.uk/
>
>
>
>
> > I'm going to replicate my code review comments here :)
>
> > * I'm not sure about specifying value given that it's a shortcut for
> > getAttribute("value")
>
> > * Could TimeUnit be more strongly typed?
>
> > * Cookie handling seems strangely lumped together with meta driver
> > management - maybe we should pull out a Cookies or CookieJar interface
>
> > * TargetLocator.frame(String nameOrId); - nameOrId: Ick.
>
> > > Few questions:
> > > Are we going to split this up into multiple IDLs so we can show
> > dependencies
> > > better?
> > > Are we going to be keeping the value attribute? Since that is just
> > > getAttribute("value")? I have seen talk about this before and think that
> > its
> > > a good idea to simplify it.
> > > Happy for us to start piling in with documentation?
> > > David
> > > David Burns
> > > URL:http://www.theautomatedtester.co.uk/
>
> > > On Sat, Mar 5, 2011 at 11:41 PM, Simon Stewart <
>
> > >> On the list is probably best, though you can also do a code review of
> > the
> > >> checked in revision. I'm happy with either.
>
> > >> Simon
>
>
> - Show quoted text -
Daniel Wagner-Hall
David Burns
Jari Bakken
<david...@theautomatedtester.co.uk> wrote:
> Google Code fail. All that is visible to me is a +1 from Dave Hunt as you
> can see in the screenshot.
>
Yeah - I can't see any comments either.
Daniel Wagner-Hall
Clint Talbert
Having a very generic name of "ManageOptions" or "Manage" or "Manager"
isn't really going to be helpful for new folks learning the API. I'd
prefer it to be more explicit, but I'm still rather unfamiliar with your
API so I can't suggest anything decent... :( Right now, it appears to
only manage cookies and timeouts. Can you break that into two
interfaces? ManageCookies & ManageTimeouts? If you did that would we be
flooded with Manage* interfaces? If there are going to be 10
Manage<foo> interfaces, then my solution is subpar.
First two cents...
Clint
Simon Stewart
On Mon, Mar 7, 2011 at 7:34 AM, Daniel Wagner-Hall <dawa...@gmail.com> wrote:
> I'm going to replicate my code review comments here :)
>
> * I'm not sure about specifying value given that it's a shortcut for
> getAttribute("value")
Good point. Removed.
> * Could TimeUnit be more strongly typed?
That'd be good. All I need to do is find the right WebIDL incantation.
Suggestions always appreciated.
> * Cookie handling seems strangely lumped together with meta driver
> management - maybe we should pull out a Cookies or CookieJar interface
CookieJar is a nice idea. I view the "Manage" interface as something
that maps to a browser's "Preferences" window.
> * TargetLocator.frame(String nameOrId); - nameOrId: Ick.
Well, agreed. Any alternatives? The one that leaps to mind is to
accept a Locator, though we'd need to clearly document which ones we
could pass in.
Simon
Bill Ross
> > management - maybe we should pull out a Cookies or CookieJar interface
>
> CookieJar is a nice idea. I view the "Manage" interface as something
> that maps to a browser's "Preferences" window.
Staying with the camelcase noun approach, how about PreferencesManager interface?
Bill
Simon Stewart
Answers inline
On Mon, Mar 7, 2011 at 6:42 PM, Clint Talbert <ctal...@mozilla.com> wrote:
> I agree with all of this, especially the bits about the cookie management.
>
> Having a very generic name of "ManageOptions" or "Manage" or "Manager" isn't
> really going to be helpful for new folks learning the API. I'd prefer it to
> be more explicit, but I'm still rather unfamiliar with your API so I can't
> suggest anything decent... :(
In a way, it makes you the perfect person to comment :)
> Right now, it appears to only manage cookies
> and timeouts. Can you break that into two interfaces? ManageCookies &
> ManageTimeouts? If you did that would we be flooded with Manage*
> interfaces? If there are going to be 10 Manage<foo> interfaces, then my
> solution is subpar.
I view the Manage interface as the equivalent of the Preferences or
Options menu in a browser, providing access to underlying
functionality that's useful but harder to surface in the UI.
Currently, the only things that we're exposing in this way are the
cookies and timeouts. Daniel's idea of adding a "cookie jar" interface
maps into that quite naturally ---- almost all browsers have a
separate tab or control panel for managing cookies. In this case, my
gut feeling is that in this case, breaking out the cookies is a good
idea.
> First two cents...
Good to hear from you!
Simon
> Clint
> On 3/7/2011 4:34 AM, Daniel Wagner-Hall wrote:
>>
>> I'm going to replicate my code review comments here :)
>>
>> * I'm not sure about specifying value given that it's a shortcut for
>> getAttribute("value")
>>
>> * Could TimeUnit be more strongly typed?
>>
>> * Cookie handling seems strangely lumped together with meta driver
>> management - maybe we should pull out a Cookies or CookieJar interface
>>
>> * TargetLocator.frame(String nameOrId); - nameOrId: Ick.
>>
>> On 7 March 2011 10:57, David Burns<david...@theautomatedtester.co.uk>
>> wrote:
>>>
>>> Few
>
Simon Stewart
One reason for picking the "manage" name is that it reads well:
"manage.cookies" and "manage.timeouts". Admittedly, there's no need
for the attribute name and its type to be the same, but there's a
pleasing symmetry to it. There's also a natural tension between
"perfect" names and those that mirror the existing code. To reflect
this, the name of the interface should really be Options. Quite what I
was thinking when I called it "Manage" I don't know.
Simon
Simon Stewart
On Mon, Mar 7, 2011 at 9:28 AM, Jim Evans <james.h....@gmail.com> wrote:
> I hadn't submitted anything yet. I'd planned to simply put my thoughts
> out here on the list, as per Simon's suggestion.
>
> To that end, my initial thoughts are as follows:
>
> I wholeheartedly, and enthusiastically support proposing a set of
> interfaces as a standard. Our job as creators of tools to enable
> testers create automated tests can only be made easier when we can
> point to a standard for browser vendors to adhere to. In doing so,
> however, we are opening the API up to a lot of scrutiny to a much
> larger audience than we have previously. How willing are we to adjust
> our IDL to the suggestions of the larger "web standards" community?
This process of standardisation is going to require a number of
compromises. Fortunately we're not trying to invent a standard API
using the awesome power of wishful thinking, we've got a fairly stable
API to build from. It means that the IDL will change, and that will be
reflected in our APIs, but we're not going to be making major changes
without discussion, and given the choice between a slightly nicer name
and stability in API, I'll almost always go for stability.
I'd appreciate being held to that :)
> Are we willing to break the existing API implementation, and by
> extension existing user code bound to the current version of the API,
> to conform to the IDL?
We've got an established way of changing APIs in the project already
(marking as deprecated, waiting a release, deleting as necessary) The
last really major renaming the project went through was when we
migrated the package name of the project to "org.openqa". It wasn't a
huge amount of fun, but it was manageable.
> Regarding the Manage and Navigate interfaces, I know these are the
> names of the methods in the Java implementation, but shouldn't the
> interface name be a noun? Looking through the other web standard IDLs,
> I don't see any interfaces with names that are verbs. Suggestions:
> OptionsManager and Navigator (though Navigator may be confusing, since
> it conflicts with an existing HTML5 interface name).
I've reverted it to Options, matching the name in the Java and .Net names.
> There is currently no IDL for RenderedWebElement, et al. I realize
Or for JavascriptExecutor, which is a fairly massive omission.
> that the user interaction API isn't represented yet; I look forward to
> it being so, and some of the methods on these additional interfaces
> are subsumed by that API. I know that not every browser that we
> support renders content (I'm looking at you HtmlUnit). Nevertheless,
> it seems to me that we could benefit from formalizing and
> standardizing the additional interfaces. Perhaps some of this goes
> back to the discussion of what should really be represented in the
> WebElement interface and whether it makes sense to reorganize the
> RenderedWebElement and Locatable interfaces.
Agreed. We're not far from beta 3, but once that's out the door, I
suggest we start making the modifications to the
WebElement/RenderedWebElement interfaces.
> I can see now through the formalization of the IDL that several things
> that are currently methods in the .NET bindings should, in fact, be
> read-only properties. I need to figure out whether to make the
> changes, and if so, how to properly communicate these breaking changes
> to the user base.
Are there any that stand out in particular?
Simon
Jim Evans
perspective. Things like the IWebDriver.GetWindowHandle() method
should really be the IWebDriver.WindowHandle property. Stuff like
that. I should really get those properties and methods marked as
deprecated before 2.0b3. :)
On Mar 7, 10:38 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> Inline. Thanks for the thoughts Jim.
>
Daniel Wagner-Hall
>> * Cookie handling seems strangely lumped together with meta driver
>> management - maybe we should pull out a Cookies or CookieJar interface
>
> CookieJar is a nice idea. I view the "Manage" interface as something
> that maps to a browser's "Preferences" window.
I was more seeing something like:
driver.cookies().add(someCookie) than
driver.manage().cookies().addCookie(someCookie) - I view cookies as a
more cross-concern issue than just preferences management (they're
things I care about on specific pages more than in a preferences
management way), but I'm happy to be argued against :)
