-
Notifications
You must be signed in to change notification settings - Fork 575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
865 aliases for kotlin #870
Conversation
@asolntsev @BorisOsipov From my point of view - it shouldn't be a part of selenide codebase, it should be implemented on client side if needed. |
@jkromski @rosolko @BorisOsipov
I think we can add methods |
I don’t like find() because SelenideElement x=find(“…); doesn’t search and
doesn’t find and it is misleading.
Viele Grüße
Alexei Vinogradov
On 7. December 2018 at 23:42:08, Andrei Solntsev (notifications@github.com) wrote:
@jkromski <https://github.com/jkromski> @rosolko
<https://github.com/rosolko> @BorisOsipov <https://github.com/BorisOsipov>
1. I don't like findX and findAllX, but
2. I like find and findAll
I think we can add methods find and findAll - they can be used in Kotlin,
why not. It's better than s, S and other meaningless suggestions. Why not?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#870 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGQ4YK_H1Wt2wlgOPGLNgH0r3HdjFDt-ks5u2u69gaJpZM4Y7szp>
.
|
It actually defines how it should be searched/located/found.
Lets try another names?
Viele Grüße
Alexei Vinogradov
On 7. December 2018 at 23:47:06, Alexei Vinogradov (alexei@vinogradoff.de)
wrote:
I don’t like find() because SelenideElement x=find(“…); doesn’t search and
doesn’t find and it is misleading.
Viele Grüße
Alexei Vinogradov
On 7. December 2018 at 23:42:08, Andrei Solntsev (notifications@github.com) wrote:
@jkromski <https://github.com/jkromski> @rosolko
<https://github.com/rosolko> @BorisOsipov <https://github.com/BorisOsipov>
1. I don't like findX and findAllX, but
2. I like find and findAll
I think we can add methods find and findAll - they can be used in Kotlin,
why not. It's better than s, S and other meaningless suggestions. Why not?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#870 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGQ4YK_H1Wt2wlgOPGLNgH0r3HdjFDt-ks5u2u69gaJpZM4Y7szp>
.
|
if you don't like @asolntsev I removed findX and findAllX BTW. @vinogradoff Could you please don't add previous messages in yours, it creates noise. It is harder to read through what you exactly mean. |
I don't like verbs here. This method defines how element will be searched. But it doesn't search. We have element() or el() as other candidates... |
looks good to me. It seems that it doesn't have to be a verb then. |
@jkromski I still don't see any problems with Actually Selenide already has very similar methods |
lol, actually never knew about getElement (est. 2013) which is alias to $.
But element looks preciser. Still I would deprecate getElement() for both
element() and el() as a shorter version of “element”
$() is by far most used function in Selenide- it makes sense to have a
short version .
Viele Grüße
Alexei Vinogradov
On 12. December 2018 at 22:56:35, Andrei Solntsev (notifications@github.com) wrote:
@jkromski <https://github.com/jkromski> I still don't see any problems with
find and findAll.
element/elements is also a good option (except that it's too long).
Actually Selenide already has very similar methods getElement/getElements.
Does changing getElement to element really matter? I am not sure...
So, by the moment, I suggest to make a pause until we find some shorter
name or agree on find.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#870 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGQ4YN2O7SKRHQzUTi34e68CpCu9O9zgks5u4XuRgaJpZM4Y7szp>
.
|
I think we need to look at it in bit wider scope and look at the SelenideElement and WebDriver methods too. Lets consider what we got in scenario like:
so for now we got names: a. Getting all arguments from @vinogradoff, @asolntsev and @BorisOsipov (but Boris is against whole idea) and me, my view is: I would go with A now. I would go with B if we agree to refactor other names from thoughts? |
Jacek, actually we don't have a use case for "search" an element, you need element either to interact with it or to assert some of his properties, but not just to "search". so Analogy. Let's say you have WYSIWYG palette in Delphi/VB/Visual C++ whatever IDE. Then you code something. You probably need to interact with some widgets on the canvas (e.g. I want to write tests the same way. Element declared with their locating methods/expressions, and then used for interacting or assertions. Luckily it is also the way Selenide works now. That's why I don't want to have declaration to look like search operation. |
Then I take your examples, but with arguments right above. I just use To declare an element use: To declare an element inside another element use: To interact with previously defined element use: To assert properties of previously defined element use: Does it make sense? |
so you saying point b in my list should be: to sum up, we got: but @asolntsev mentioned that it would better to have shorter name, |
Can we agree on what to do over here? But I can do what you decide/agree |
@jkromski it seems that we don't have an "ideal" solution that would be better than current state. P.S. I found some symbols that are allowed in Kotlin. Probably we could use on of them instead of Œ(".active")
Š(".active")
ƒ(".active")
œ(".active")
Ÿ(".active")
ª(".active")
µ(".active")
À(".active") |
the symbols you gave I cannot find on the keyboard and I guess most of the people won't so it will be pain in the ... to use it in any language. |
can we make a decision over here, I would love to finish it and start something else. I guess people using Kotlin would like to have it released too |
Since we haven't a common opinion now, I suggest to avoid doing anything
(until we find a good idea that we all like).
…On Wed, Jan 9, 2019, 14:29 Jacek ***@***.*** wrote:
can we make a decision over here, I would love to finish it and start
something else. I guess people using Kotlin would like to have it released
too
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#870 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARE3f-ouqspB5UywfbcVBgxfP_Qgs5lks5vBeCzgaJpZM4Y7szp>
.
|
To be honest, right now after doing some more tests, I think @vinogradoff proposition make a lot of sense as it fits scenarios which I mentioned before and if you would like to assure that element does not exists then you got:
|
Wow.
This is really a great argument. I absolutely agree that both
`find("a.link").shouldNot(exist)` and
`getElement("a.link").shouldNot(exist)` do not sound good, while
`element("a.link").shouldNot(exist)` is perfect.
So, let's create method `element` and deprecate method `getElement`.
And what about collections? Does `elements("a.link").shouldBe(empty)` sound
good? And `elements("a.link").shouldHave(size(5))`?
…On Thu, Jan 10, 2019, 19:05 Jacek ***@***.*** wrote:
To be honest, right now after doing some more tests, I think @vinogradoff
<https://github.com/vinogradoff> proposition make a lot of sense as it
fits scenarios which I mentioned before and if you would like to assure
that element does not exists then you got:
element("a.link").shouldNot(exist)
which is very intuitive.
find("a.link").shouldNot(exist) does not make much sense here
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#870 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARE3SBQUJS2-EeFT0DtzoWol8sAKpmoks5vB3LOgaJpZM4Y7szp>
.
|
yup, collections looks good too. Shall I mark find* methods deprecated too or we leave it for later? |
@jkromski Just introduce |
I have another idea for collections. Actually This looks right: Downside: these are pretty long names. |
@vinogradoff personally I prefer element/elements. It was long discussion and I think at the end your proposition was the best. Pull request is ready to be re-reviewed |
I am okay with elements
|
let's also deprecate find? |
Proposed changes
#865
Checklist
gradle check chrome htmlunit
command - there are error not related with this change