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.
-
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.
-
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