RenderedWebElement and its future
David Burns
the past and I was wondering if that is still the case. I have just
noticed that the python bindings do not have a RenderedWebElement and
have some of the RenderedWebElement stuff in WebElement.
So what is the future of the these 2 objects so that I can sort the
python bindings.
David Burns
http://www.theautomatedtester.co.uk
Simon Stewart
APIs, such as "hover" have already been deprecated and will be removed
in beta 2. The remaining methods are actually do with whether the
element is rendered or not. I'm still in two minds about removing it
entirely. There are 3 obvious candidate methods to move (with the
"getValueOfCssProperty" being the one I'm not sure about --- it's not
a good method name, and it hints that there's missing concept in the
API) On WebElement itself, "getValue" is merely a convenience method
for "getAttribute('value')" and is a candidate for deprecation, and
"toggle" seems sufficiently underused to be moved to the user
interactions API.
If we remove the suggested methods and move the sane ones from
RenderedWebElement, we're looking to expand the API of WebElement by 1
or 2 methods. I could live with that.
The problem with RWE is that it reduces the explorability of the API
--- it's not obvious that these methods exist. IME, the most commonly
used method is "isDisplayed", so there is a possibility of just moving
that method and leaving "getLocation" and "getSize" on RWE. As you can
see, I'm still pondering deeply about RenderedWebElement :)
For the python bindings, I'd not bother with the subclass, but I
wouldn't add the deprecated methods, and I'd remove the deprecated
ones from WebElement, if only because Python IDEs don't make it as
easy to explore the API as Java IDEs do, so favouring a flatter class
hierarchy seems to make sense.
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.
>
>
Jari Bakken
<simon.m...@gmail.com> wrote:
>
> For the python bindings, I'd not bother with the subclass, but I
> wouldn't add the deprecated methods, and I'd remove the deprecated
> ones from WebElement, if only because Python IDEs don't make it as
> easy to explore the API as Java IDEs do, so favouring a flatter class
> hierarchy seems to make sense.
Right. We only have the WebDriver::Element class in Ruby, and likewise
#execute_script is available on Driver without any extra work for the
user (i.e. no JavascriptExecutor). I'm sure there are other examples
of a flatter hierarchy as well.
David Burns
I am all for a flatter structure but in reality it wouldn't matter for bindings. The question was more an API question since in Java/C# we need to cast to RWE to get the other items when intuitively a webelement is a webelement whether it is rendered or not.
David Burns
On Jan 2, 2011 9:40 PM, "Jari Bakken" <jari....@gmail.com> wrote:On Sun, Jan 2, 2011 at 10:11 PM, Simon Stewart <simon.m...@gmail.com> wrote: > > For the python...
Right. We only have the WebDriver::Element class in Ruby, and likewise
#execute_script is available on Driver without any extra work for the
user (i.e. no JavascriptExecutor). I'm sure there are other examples
of a flatter hierarchy as well.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" grou...
Simon Stewart
had my time again, it'd be a role-based interface called something
like "Displayable". The reason it exists as a separate class is that
not browsers actually render content (HtmlUnit was the original
example of this) I'm definitely not keen on adding AWT dependencies to
the core interface, though that may be a highly irrational point of
view.
And, for Jari and posterity, here's a link to the very first version
of the WebDriver interface, as checked in 4 years ago:
Interesting things: the finding elements methods are awful, offering
up a terrible proliferation of methods as mechanisms increased,
there's no way of switching between windows or frames, and executing
Javascript lived on the main interface and couldn't return anything.
Simon
Jim Evans
place where WebElement probably needs extending: the new advanced user
interactions API. In the present Java implementation, the Keyboard and
Mouse interfaces are accessible through getters on WebDriver, and to
interact with an element, you pass the WebElement into the methods on
those interfaces. This seems counterintuitive to me.
As a consumer of the API, I would expect the WebElement interface (or
something I can cast it to) to have the interaction methods
(doubleClick, contextClick, etc.). Indeed, the concrete
RemoteWebElement class is coded that way, with those interaction
methods on the object. However, we are encouraging our users to code
against the interfaces and not the implementations, yes? This API
design, then, would seem to fly in the face of that.
I suppose the ultimate decision on how the API looks is "above my pay
grade", as the saying goes, and I can code the .NET bindings to be
compatible with whatever direction we choose to go. Having said that,
I was wondering if someone (Simon?) could share the logic behind the
API design. I suppose you could make the case that using the getters
is more discoverable via an IDE, but I still think the usage feels
cumbersome. Are we going to be placing a premium on discoverability
going forward? If so, let me add my voice to the chorus that says we
probably need to rethink RenderedWebElement.
On Jan 3, 7:43 am, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> The RenderedWebElement was the first time I extended the raw API. If I
> had my time again, it'd be a role-based interface called something
> like "Displayable". The reason it exists as a separate class is that
> not browsers actually render content (HtmlUnit was the original
> example of this) I'm definitely not keen on adding AWT dependencies to
> the core interface, though that may be a highly irrational point of
> view.
>
> And, for Jari and posterity, here's a link to the very first version
> of the WebDriver interface, as checked in 4 years ago:
>
> Interesting things: the finding elements methods are awful, offering
> up a terrible proliferation of methods as mechanisms increased,
> there's no way of switching between windows or frames, and executing
> Javascript lived on the main interface and couldn't return anything.
>
> Simon
>
> On Sun, Jan 2, 2011 at 9:55 PM, David Burns
>
>
>
> <david.bu...@theautomatedtester.co.uk> wrote:
> > I am all for a flatter structure but in reality it wouldn't matter for
> > bindings. The question was more an API question since in Java/C# we need to
> > cast to RWE to get the other items when intuitively a webelement is a
> > webelement whether it is rendered or not.
>
> > David Burns
>
>
> > On Sun, Jan 2, 2011 at 10:11 PM, Simon Stewart <simon.m.stew...@gmail.com>
Simon Stewart
"click" and "sendKeys") live on WebElement as a convenience. The
problem comes as we decide where to draw the line about which methods
to add where. For example, in some apps drag and drop may be more
heavily used than double clicking, but in others the opposite may be
true.
The idea with the advanced user interactions API is that users don't
use Mouse and Keyboard directly. Instead, users should be using the
ActionsChainGenerator to create the more advanced actions. In my head,
I imagine it being used something like:
Actions.with(driver).doubleClick(element).perform();
Essentially, the "Actions" class is a builder, allowing a complex
series of actions to be grouped together:
Actions.with(driver).clickAndHold(By.id("foo"))
.hold(Keys.SHIFT)
.click(By.id("e2"))
.click(By.id("e3"))
.release(Keys.SHIFT)
.dragLeft(100).dragDown(200)
.releaseMouseButton()
.perform();
I'm totally open to reworking the RenderedWebElement, but I'm not
happy with just dumping action methods into it (emphasized for effect:
I know that's not what you meant Jim) I'm also not particularly
pleased with it having a dependency on AWT, though it's hard to come
up with a rational reason for that dislike.
Simon
Jim Evans
ActionSequenceGenerator better than ActionsChainGenerator, but that's
a silly thing to quibble over. Since the generator always requires a
WebDriver reference, does it make sense to have a
getActionsChainGenerator method on WebDriver that returns a generator
bound to the driver instance? Might be a dumb suggestion, but it might
help with discoverability of the API.
Simon Stewart
challenge. I think my preference is to see how people use the API once
it's more stable and decide from there. My suspicion is that this is a
"power user" feature, and those are the sort of people who are more
likely to read docs, but without some real-world data it's hard to
judge. It looks like people are already finding out about
"HasInputDevices" without needing much prompting....
Simon