Replies: 2 comments 6 replies
-
|
Thanks for sharing your detailed observations on the topic @iFatRain It is true, that very few changes are being added to widgets since this was implemented as a result of a personal initiative of the former project contributor. Also, the implementation itself is fairly complicated as well as the whole page-object concept. My advices to that would be:
|
Beta Was this translation helpful? Give feedback.
-
|
Absolutely! A very simple 'fix' would be to re-arrange the order of the WebElement vs Widget check so that it always checks if it is a Widget first. I don't imagine this would cause any kind of compatibility issues, but my concern would be on the performance side. In the scope of an entire regression suite, how impactful would it be for WebElements to have that additional call to check if is a Widget implementation first? Thats something that would need at least a guess thrown at |
Beta Was this translation helpful? Give feedback.
-
|
maybe create a PR first to demonstrate your idea. If it passes existing tests then we'd have at least some confidence nothing in the legacy behaviour is going to be broken |
Beta Was this translation helpful? Give feedback.
-
|
@mykola-mokhnach You can have a peek at this draft: #2277 |
Beta Was this translation helpful? Give feedback.
-
|
I would say the abovechange is ok if it does not break the backward compatibility @valfirst @SrinivasanTarget @saikrishna321 What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Awesome news, would be a nice quick "fix" for the behavior I'm after if all agree that it wouldn't be costly performance wise. I am also working on a side project to introduce an extendable element type situation directly into Selenium that tries to adhere to the core philosophy as much as it can, and the changes be as limited as possible. Which if that goes well could also have cool impacts downstream within Appium. |
Beta Was this translation helpful? Give feedback.
-
|
Another thought that has come to mind; In some aspects I understand the philosophy behind Widgets and its implementation as a (mostly exclusive) container of a collection of elements. So I also had the idea that instead of modifying the current implementation of Widget, perhaps a better approach might be to explicitly allow an extendable WebElement type class that is intended for uses as a single entity with special capabilities; Like the checkbox, toggle switch, ect. and other such cases where you may want to provide a common set of extended capabilities to an element type in your application, rather than setting up a generic utility to pass an element into to achieve that functionality. This would allow Widgets to maintain their identity for "grouped" sections of elements, while also giving a path towards singular elements with extended capabilities to allow a little easier reuse for some common cases you may come across.* *However, you'd have to keep in mind because of the nature of design and what an element inherently is (See SearchContext as the basis for this argument), this would also allow the custom element to be used almost identically in nature to what Widget already fulfills ideologically. |
Beta Was this translation helpful? Give feedback.
-
|
As such this above proposed solution would add a 3rd even more fine (lower level) of abstraction targeted at individual WebElements themselves, thus from highest abstraction to lowest, you have->
I also wanted to add that fundamentally, Pages and Widgets are no different from one another, except for intended abstraction layer is concerned. They're both essentially containers of WebElements within. Furthering this line of reasoning, if you were to enable a Extendable and Customizable WebElement, there would be in theory nothing stopping you from placing a PageFactory within that custom element implementation, once again rending it functionally equal to a Page or Widget in this example. So at that point, is the answer a unified approach of having a CustomElement exclusively, and to change the approach of POM (which is ultimately focused around having maintainable groupings of functionality, often divided into "Pages" and/or Panels (widgets in appium)) to have Pages essentially be nearly like a "top level" WebElement but without implementing the WebElement interface (since I don't imagine you want to blindly click on the center of a page for example)?? Food for thoughts. |
Beta Was this translation helpful? Give feedback.
-
Where to begin...
So at my company I introduced code very similar to this extendable WebElement approach discussed here. Which after looking into this happens to be every similar to the original inspiration mentioned in #228 of HTMLElements and in particular this TypifiedElement which was likely a earlier version of ElementImpl in Selophane.
I have been using this in my project for several years now and it saved me an incredible amount of development and maintenance time. I often try to think of a developer who made a generic "widget" on the webpage that gets duplicated and reused frequently, and gets populated with different data depending on context. As such I felt it was only logical to mimic that design with automation. I tend to think of these as element groupings or perhaps 'Containerized' elements. Elements which will be commonly used and reused but contain a wide array of data depending on context.
Recently, I have moved into the mobile world and wanted to have similar tools at my disposal. I was very pleased to find that Appium provides the Widget class out of the box! However, my honeymoon was shortlived. My immediate complaint likely stems from differences in design philosophy of Widget, in which to me it behaves much more like a 'nested page' or a 'page on a page' (When considering Page Object Model) instead of a true WebElement. What I mean by this is that, by design, a Widget appears that it typically isn't meant to be singular element or useful on its own, and instead is meant to be a container of multiple elements internally (Which is the typical case even for me). As such it cannot be passed into methods which intake WebElement without first calling the getWrappedElement() method which for me got very tedious because of the code libraries we have that are designed for WebElement and not for Widgets; and I just didn't want to always have to make that extra method call in code. My immediate thought was "Well I'll just create an extension of this that conforms to my taste and implement the WebElement interface there, and use that as my basis for my widgets. NOT SO FAST! As luck would have it, it turns out this doesn't work by design because of the order of operations when checking type of WebElement vs Widget as seen here. The TL;DR; is that as soon as your Widget extension implements the WebElement class and can be used interchangable, it is now seen as a WebElement itself, and thus doesn't ever trigger the Widget's decorator, and ultimately it will fail to be decorated and proxied correctly.
The two 'solutions' that seem apparent would be:
To swap the order of these calls (I have tested and it seems to work out, seeing if something is an extension of the Widget class first, and if not try for WebElement) however my immediate concern would be the overhead this could cause for regular WebElement calls which for most folks are undoubtedly more common.
To change the fundamental implementation (and thereby philosophy) of the Widget and have it natively act as a WebElement instead of what in my opinion is a sort of page-on-page like solution. (Widget has been mostly untouched since it was introduced way back). This is the way more drastic and breaking change solution.
So before I opened an issue for a possible change, I did want to at least open some discussion and get some thoughts and viewpoints I maybe haven't considered in depth myself and potentially try to find a solution (or decide to leave as-is).
I am very curious to hear what others thoughts might be on this
Later edit
I wanted to also give some examples that I have faced in my own work of when the Widget itself would be an intractable or singular. I would mention Checkboxes or expand/collapse panels as singular elements that would have some common reuse you want to impart on (Stateful elements). And then as far as complex widgets where the container itself may be interacted with, I have faced examples of movable tiles, re-orderable layouts, ect.
Beta Was this translation helpful? Give feedback.
All reactions