JTAF-ExtWebDriver icon indicating copy to clipboard operation
JTAF-ExtWebDriver copied to clipboard

DragAndDrop should be in Element not in InteractiveElement

Open opensource21 opened this issue 10 years ago • 7 comments

I can't find any reason, why it is in In InteractiveElement? You can DragAndDrop every WebElement.

Furtermore the code is to complicated

builder.dragAndDrop(this.getWebElement(), 
        new InteractiveElement(element.getByLocator()).getWebElement()).build().perform();

Should be

builder.dragAndDrop(this.getWebElement(), 
            element.getWebElement()).build().perform();

opensource21 avatar Aug 09 '14 18:08 opensource21

I agree with the code fix but I would still leave it inside of IInteractiveElement interface. The reason is since we want to keep all interacting methods within IInteractiveElement. IElement should be the base widget that simply represents any web element in the DOM.

http://finraos.github.io/JTAF-ExtWebDriver/widgetlibrary.html

kood1 avatar Aug 09 '14 18:08 kood1

But you can drag and drop an image, so than it must be Interactive.

opensource21 avatar Aug 11 '14 08:08 opensource21

Image is already extending InteractiveElement and it should be within InteractiveElement category. Table, however, probably should not be extending InteractiveElement as the columns, rows, inside can be interactive, but not the table element itself.

Thoughts everyone?

kood1 avatar Aug 11 '14 12:08 kood1

About Image you are right. I trusted the link you give. There an image is static ;-)

opensource21 avatar Aug 11 '14 12:08 opensource21

That should be fixed :-)

kood1 avatar Aug 11 '14 12:08 kood1

"Image is already extending InteractiveElement and it should be within InteractiveElement category. Table, however, probably should not be extending InteractiveElement as the columns, rows, inside can be interactive, but not the table element itself.

Thoughts everyone?"

I'm OK with making Table non-interactive, maybe we could provide a way to hand back an InteractiveElement of a chosen row/column instead of the whole table being extended off of InteractiveElement, of course this would imply the user knows what kind of things he's got inside of his table.

SMxJrz avatar Aug 11 '14 13:08 SMxJrz

The only interaction i can think of on table itself would be pagination or any tool bar actions. But those can be implemented as separate widgets. And more over they are mostly app specific. Considering that the table need not be an interactive element. Apart from that we need to objectify each cell (or row/column) to be interactive elements. We need to make them extensible too. So any customizations on interaction can be easily done by only implementing the extensions of the row/column widgets.

lathanagaraj avatar Aug 11 '14 14:08 lathanagaraj