You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ability to search for and navigate via elements within an element via a component #61
Panel: UiComponent
WebElement // After this is initialised this needs to be set
ClickClose()
var closeElement = WebElement.FindElement(By.CssSelector("div.close"))
closeElement.Click()
var close = GetComponent<ConfirmPanelClose>()
close.WebElement = closeElement
return close
Manage()
WebElement.FindElement(By.CssSelector(".manage")).Click()
return GetComponent<ManagementPage>()
ConfirmPanelClose : UiComponent
WebElement
ClickConfirm()
WebElement.FindElement(By.TagName("a")).Click()
It would be cool if you could make use of a new base class, something like:
UiComponentWithElement : UiComponent
SetElement(IWebElement)
Element
WithinMyElement
Find()
Navigate()
...
And then the above would become something like: ...
Panel: UiComponentWithElement
ClickClose()
var close = WithinMyElement.Find().Element<ConfirmPanelClose>(By.CssSelector("div.close"))
close.Element.Click()
return close
Manage()
return WithinMyElement.Navigate().To<ManagementPage>(By.CssSelector(".manage"))
ConfirmPanelClose : UiComponentWithElement
ClickConfirm()
WithinMyElement.Find().Element(By.TagName("a")).Click()
When we get a Find().Elements() it would be cool if that could have an overload that takes a UiComponentWithElement generic type too...
I've been thinking about the right way to do this the last couple of days.
I wonder if there's a neater way something akin to how Selenium's IWebDriver and IWebElement both inherit ISearchContext, which contains the FindElement/FindElements methods.
I'm not quite sure what you mean. Can you create a small snippet like I did above that demonstrates what that might look like from the consumers point of view?
I was kind of musing out loud about hierarchies etc. Apologies.
Page has Browser : IWebDriver, and supports finding stuff via Find()... UIComponentWithElement has IWebElement and IWebDriver and will support and supports finding stuff via Find()... and withinElements.Find()
IWebDriver inherits ISearchContext IWebElement inherits ISearchContext ElementFinder is presently tied to IWebDriver rather than ISearchContext mainly because of the need to tie into waits at the browser level. Perhaps the wait object should be injected as a dependency, alongside an ISearchContext used for the finding methods. e.g. public ElementFinder(IWait wait, ISearchContext searchContext)
From the consumer's POV, no real change, though perhaps instead of Element<TComponent>() maybe Find().Element(..).AsComponent<TComponent>()?
Incidentally (and not a big deal), I'm not sure I understand why Find().Elements() rather than Finder.FindElements(). I look at the Find(), Navigate(), Execute() etc. methods and feel odd that they're not doing anything, but just returning something to do the thing.
Also, I wonder whether it makes sense to have a UIComponent ever without an Element, even if that element is the root element? Does it make sense for an Element to be able to search, navigate etc. at the page level?
I'm just going to +1 the Find() Model() methods feel a bit odd.
Sent from my Windows Phone
From: joshkamailto:notifications@github.com
Sent: ý12/ý07/ý2013 02:32
To: TestStack/TestStack.Selenomailto:TestStack.Seleno@noreply.github.com
Subject: Re: [TestStack.Seleno] Ability to search for and navigate via elements within an element via a component (#61)
I was kind of musing out loud about hierarchies etc. Apologies.
Page has Browser : IWebDriver, and supports finding stuff via Find()...
UIComponentWithElement has IWebElement and IWebDriver and will support and supports finding stuff via Find()... and withinElements.Find()
IWebDriver inherits ISearchContext
IWebElement inherits ISearchContext
ElementFinder is presently tied to IWebDriver rather than ISearchContext mainly because of the need to tie into waits at the browser level. Perhaps the wait object should be injected as a dependency, alongside an ISearchContext used for the finding methods.
From the consumer's POV, no real change, though perhaps instead of Element() maybe Find().Element(..).AsComponent() ?
Incidentally (and not a big deal), I'm not sure I understand why Find().Elements() rather than Finder.FindElements(). I look at the Find(), Navigate(), Execute() etc. methods and feel odd that they're not doing anything, but just returning something to do the thing.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-20853682.
@joshka finally had a chance to absorb your suggestions.
Sounds excellent! Great work.
I'm really eager to do more work on Seleno again so hopefully I can find some time after my UG presentation next week to work on this and a few of the other items on the backlog like finding multiple elements.
Activity
joshka commentedon Jul 11, 2013
I've been thinking about the right way to do this the last couple of days.
I wonder if there's a neater way something akin to how Selenium's IWebDriver and IWebElement both inherit ISearchContext, which contains the FindElement/FindElements methods.
robdmoore commentedon Jul 11, 2013
I'm not quite sure what you mean. Can you create a small snippet like I did above that demonstrates what that might look like from the consumers point of view?
joshka commentedon Jul 12, 2013
I was kind of musing out loud about hierarchies etc. Apologies.
PagehasBrowser : IWebDriver, and supports finding stuff viaFind()...UIComponentWithElementhasIWebElementandIWebDriverand will support and supports finding stuff viaFind()... andwithinElements.Find()IWebDriverinheritsISearchContextIWebElementinheritsISearchContextElementFinderis presently tied toIWebDriverrather thanISearchContextmainly because of the need to tie into waits at the browser level. Perhaps the wait object should be injected as a dependency, alongside anISearchContextused for the finding methods. e.g.public ElementFinder(IWait wait, ISearchContext searchContext)From the consumer's POV, no real change, though perhaps instead of
Element<TComponent>()maybeFind().Element(..).AsComponent<TComponent>()?Incidentally (and not a big deal), I'm not sure I understand why
Find().Elements()rather thanFinder.FindElements(). I look at theFind(),Navigate(),Execute()etc. methods and feel odd that they're not doing anything, but just returning something to do the thing.joshka commentedon Jul 12, 2013
Also, I wonder whether it makes sense to have a UIComponent ever without an Element, even if that element is the root element? Does it make sense for an Element to be able to search, navigate etc. at the page level?
JakeGinnivan commentedon Jul 12, 2013
I'm just going to +1 the Find() Model() methods feel a bit odd.
Sent from my Windows Phone
From: joshkamailto:notifications@github.com
Sent: ý12/ý07/ý2013 02:32
To: TestStack/TestStack.Selenomailto:TestStack.Seleno@noreply.github.com
Subject: Re: [TestStack.Seleno] Ability to search for and navigate via elements within an element via a component (#61)
I was kind of musing out loud about hierarchies etc. Apologies.
Page has Browser : IWebDriver, and supports finding stuff via Find()...
UIComponentWithElement has IWebElement and IWebDriver and will support and supports finding stuff via Find()... and withinElements.Find()
IWebDriver inherits ISearchContext
IWebElement inherits ISearchContext
ElementFinder is presently tied to IWebDriver rather than ISearchContext mainly because of the need to tie into waits at the browser level. Perhaps the wait object should be injected as a dependency, alongside an ISearchContext used for the finding methods.
From the consumer's POV, no real change, though perhaps instead of Element() maybe Find().Element(..).AsComponent() ?
Incidentally (and not a big deal), I'm not sure I understand why Find().Elements() rather than Finder.FindElements(). I look at the Find(), Navigate(), Execute() etc. methods and feel odd that they're not doing anything, but just returning something to do the thing.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-20853682.
robdmoore commentedon Jul 12, 2013
Agreed :)
I hope to remove them at some point before 1.0.
robdmoore commentedon Jul 17, 2013
@joshka finally had a chance to absorb your suggestions.
Sounds excellent! Great work.
I'm really eager to do more work on Seleno again so hopefully I can find some time after my UG presentation next week to work on this and a few of the other items on the backlog like finding multiple elements.
Fixes TestStack#61: replaced some methods /w properties for more fluency