add datamatcher #335
add datamatcher #335
Conversation
| def _build_data_matcher(self, name=None, args=None, className=None): | ||
| result = {} | ||
|
|
||
| for key, value in {'name': name, 'args': args, 'class': className}.items(): |
There was a problem hiding this comment.
Python 3 has only items()
|
|
||
| return json.dumps(result) | ||
|
|
||
| def find_element(self, by=None, value=None): |
There was a problem hiding this comment.
are these dummy methods needed?
| raise NotImplementedError | ||
|
|
||
|
|
||
| class WebDriverSearchContext(webdriver.Remote, |
There was a problem hiding this comment.
this is still data matcher search context. How we are going to represent this if more search contexts are moved to extensions?
There was a problem hiding this comment.
how about these would be named as AndroidDriverDataMatcherSearchContext and AndroidElementDataMatcherSearchContext?
There was a problem hiding this comment.
I came up with like below. AndroidSearchContext will have data matcher, view tag and uiautomator, for example 👀
class WebDriverSearchContext(webdriver.Remote,
GeneralSearchContext,
AndroidSearchContext,
IOSSearchContext,
WindowsSearchContext,
TizenSearchContext):
There was a problem hiding this comment.
I'd rather say this is AppiumSearchContext
| raise NotImplementedError | ||
|
|
||
|
|
||
| class CommonSearchContext(RootSearchContext): |
There was a problem hiding this comment.
I think this class is not needed for now
| from appium.webdriver.common.mobileby import MobileBy | ||
|
|
||
|
|
||
| class RootSearchContext(object): |
| return json.dumps(result) | ||
|
|
||
|
|
||
| class IOSSearchContext(RootSearchContext): |
There was a problem hiding this comment.
these empty classes are also not needed for now. We'll create them when there will be a need
|
We could also create a task to refactor the other search context and move them to extensions. Just not to forget and to make it visible to other maintainers |
2 participants
No description provided.