(12:06:43 PM) jweiss: ccrouch: you were looking for an explanation of https://bugzilla.redhat.com/show_bug.cgi?id=654070
(12:08:28 PM) ccrouch: jweiss: i'm not sure how feasible its going to be to provide what he wants so I want to document in that bug the reasons this is needed
(12:08:43 PM) ccrouch: so we can think about alternatives if necessary
(12:09:31 PM) jweiss: ccrouch: i'm not exactly sure how scLocators DO work, but I know what functionality we need
(12:09:38 PM) jweiss: and i think dgao_class is saying we don't have it
(12:09:49 PM) jweiss: so i'll tell you what we need 
(12:09:52 PM) ccrouch: perfect
(12:10:45 PM) jweiss: we need to be able to identify some controls by their parents/ancestors/siblings/decendants.  eg, a checkbox whose following-sibling contains the text "Jeff".
(12:10:58 PM) jweiss: otherwise that checkbox is just like 10 other checkboxes.
(12:11:55 PM) jweiss: i think that's what dgao_class's example was - a Next button that's inside DynamicForm.  as opposed to other NextButtons
(12:12:47 PM) jweiss: "vanilla" selenium lets you do this with xpath locators.
(12:15:05 PM) ckannan: jweiss : ccrouch : how did this work in the JON 2.4 timeframe ? 
jweiss jweiss-out 
(12:15:47 PM) ckannan: jweiss : ccrouch : did our automation depend on this xpath stuff for getting the old jsf based ui automated ?
(12:16:03 PM) jweiss: ckannan: we used xpath locators like "//tr[.="jeff"]/input[@type='checkbox']"
(12:16:19 PM) jweiss: that means:  give me the checkbox whose parent row contains the text "jeff"
(12:16:42 PM) jweiss: ckannan: our automated depended very heavily on this 
(12:16:58 PM) ccrouch: jweiss: i can see how the case of multiple Buttons on the same page all having the same locator would be a bad thing, but I thought that uniqueness was already achieved
(12:17:07 PM) ***ccrouch goes to look at the wiki page
(12:17:26 PM) jweiss: ccrouch: i don't see how it is possible to generate unique and predictable ids for everything
(12:17:30 PM) jweiss: for instance, checkboxes
(12:17:32 PM) ckannan: jweiss : ccrouch : so this is essentially in some ways a regression ?
(12:17:52 PM) jweiss: they can be unique, but the automation won't be able to calculate it
(12:18:57 PM) jweiss: ccrouch: i don't know if dgao_class's example very well, to me it sounds like it could be solved with a unique id
(12:19:36 PM) jweiss: the problem comes when the element we are trying to find is associated with some dynamic content, like a JON resource name.
(12:23:10 PM) jweiss: the problem with generating id's instead of using hierarchy is that you devs have to try to guess all the relevant info to stuff into that ID
(12:23:38 PM) jweiss: and then we have to know the exact algorithm and all the necessary info that went into that ID to calculate it ourselves.
(12:23:56 PM) ccrouch: jweiss: this problem is discussed here I believe 
(12:23:56 PM) ccrouch: http://www.rhq-project.org/display/RHQ/Testing+SmartGWT+with+Selenium#TestingSmartGWTwithSelenium-AssigningExplicitIDs
(12:24:49 PM) jweiss: ccrouch: yeah it's discussed there but not solved.
(12:25:03 PM) jweiss: i doubt there's any good solution using that technique.
(12:26:13 PM) jweiss: you'd have to include all the information about the parents and siblings in the ID
(12:26:18 PM) jweiss: i don't see how that is possible.
(12:27:10 PM) ccrouch: do you have another technique to propose?
(12:27:31 PM) jweiss: it works well for hardcoded stuff, like when there is a "completed operations" section and a "in-progress ops" section, where it's known in advance what the sections are on the page.
(12:27:37 PM) jweiss: it doesn't work for purely dynamic content.
(12:28:48 PM) ccrouch: can you clarify on the underlying issue here:
(12:28:48 PM) ccrouch: whether whats described on that wiki page is insufficient  for proper testing
(12:28:48 PM) ccrouch: or that there are particular instances of us not using the techniques on the page properly
(12:29:07 PM) jweiss: ccrouch: what's described on the wiki is insufficient.
(12:30:02 PM) ccrouch: jweiss: ok that helps identify the problem
(12:30:13 PM) jweiss: ccrouch: the devil is in the details - see the "Tips" section:  "Be careful of loops generating widgets. In these cases you will need to make sure your locatorId differs on each iteration, but is still repeatable. Sometimes a resource name or some-such may be ok to use."
(12:30:29 PM) jweiss: ccrouch: that is exactly where things fall apart
(12:30:46 PM) ccrouch: jweiss: can you provide a specific example?
(12:31:37 PM) jweiss: ccrouch: the classic one for me is where we have a table display of 10 resources, with 5 columns.  checkbox , resource name, resource parent, resource type, resource plugin.
(12:31:52 PM) jweiss: i need to locate the checkbox by ANY of those columns, not just one.
(12:33:24 PM) jweiss: the automation may in one test need to "check the checkbox of the  resource whose resource plugin is JBossAS5 and parent is myplatform" 
(12:33:50 PM) jweiss: and then later it will want to find the checkbox by resource name.
(12:34:42 PM) jweiss: so in order to do that with just an ID, the ID string needs to contain all that info
(12:41:51 PM) ccrouch: so i'm not sure how having a parent/child relationship defined in the id as described in 654070
(12:41:51 PM) ccrouch: I'd also like to know how this was handled in the jsf version
(12:44:54 PM) jweiss: ccrouch: it wasn't handled in the jsf version - you didn't have to
(12:45:07 PM) jweiss: we had access to all the html elements and their attributes
(12:45:36 PM) jweiss: so we could just ask for "the checkbox whose parent row has a 4th column "myplatform" "
(12:46:58 PM) jweiss: ccrouch: the smartgwt selenium plugin already has this funcitonality
(12:47:02 PM) jweiss: http://www.jroller.com/sjivan/entry/smart_gwt_2_2_released
(12:47:08 PM) jweiss: see "selenium support"
(12:47:24 PM) jweiss: so unless you guys did something to break that, it should be there.
(12:47:40 PM) jweiss: theoretically all we need is to be able to inspect the structure so we can build those locators.
(12:47:51 PM) ccrouch: ok :-), so assuming it is there, whats the problem?
(12:47:57 PM) jweiss: none, really
(12:48:08 PM) jweiss: we just need to know how to inspect the structure.
(12:48:09 PM) ccrouch: perfect, I'll close the BZ then ;-)
(12:48:24 PM) jweiss: ccrouch: well, unless it doesn't work for some reason
(12:48:38 PM) jweiss: jshaughn-dr should be able to tell us
(12:48:47 PM) jweiss: i am not sure why he didn't try this
(12:49:01 PM) ccrouch: ok, it sounds like the next step is to have dgao_class check to see if that selenium support you described is sufficient for him
(12:49:08 PM) jweiss: we can't because we don't have a dev environment to be able to build a locator like on the page i pasted.
(12:49:26 PM) jweiss: we don't know what row id's are inside what ListGrid, etc
(12:49:36 PM) jweiss: all jshaughn-dr gave us was ids
(12:50:13 PM) jweiss: i know someone - jshaughn-dr or mazz or somebody, was telling us a while back about how we can get that info
(12:50:35 PM) jweiss: there was some debate on whether we had to have a full fledged dev environment running in some kind of debug mode.
(12:50:47 PM) jweiss: if not that's great, but if so we can work with that
(12:50:57 PM) jweiss: we'll just need some help setting it up.
(12:52:09 PM) ccrouch: i dont see the relevance of a dev env, the code is either building scLocators like the linked one or its not
(12:52:47 PM) jweiss: ccrouch: what code?
(12:52:56 PM) jweiss: our code does'nt write itself
(12:53:01 PM) ccrouch: ha
(12:53:07 PM) jweiss: we need to create those locators 
(12:53:09 PM) ccrouch: you dont say :-)
(12:53:14 PM) jweiss: based on what we're looking for
(12:53:23 PM) jweiss: if we can't see the smartgwt structure, that's impossible.
(12:53:39 PM) jweiss: and if all we have is a browser, we can't see the structure
(12:55:39 PM) joseph: jweiss: ccrouch: since the only html that ever comes from the server is CoreGUI.html (because all the rest is built up by javascript that manipulates the DOM), you might be able to get by with a browser plugin that allows you to inspect the generated HTML.  FF has a plugin called 'Web Developer' that allows you to view generated source.
(12:56:17 PM) jweiss: joseph: my understanding was that we're not even locating using the dom
(12:56:31 PM) jweiss: we're using javascript objects of some kind, because each browser will actually render differently
(12:56:56 PM) ccrouch: jweiss: ok, as your link states you should be able to get this stuff out of Selenium IDE or  Smart GWT Developer console.
(12:57:09 PM) jweiss: ccrouch: seems that way to me.
(12:57:36 PM) joseph: gwt works by generating javascript that will manipulate the dom appropriate on a browser-by-browser basis.
(12:57:39 PM) jweiss: if you guys can help dgao_class get to where he can use that console, he may be all set
(12:58:03 PM) jweiss is now known as jweiss-docappt
(12:58:05 PM) ccrouch: i'd expect dgao_class to have used Selenium IDE because, thats our primary problem reproduction environment
(12:58:23 PM) joseph: granted, you may not be locating using the dom, but you should be able to get the locatorIds from the generated source
(12:58:43 PM) ccrouch: spinder-lunch, jshaughn-dr: did you guys get dgao_class setup with Selenium IDE ?
(12:59:09 PM) joseph: however, if you're looking to use that compact expression (scLocator), then you may need to know the smartgwt structure of the page, not just the pure dom

Next step is to make sure dgao is setup with Selenium IDE or Smart GWT Developer console (http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/Debugging.html). With those he should be able to determine whether the locators are being create appropriate, e.g. //ListGrid[ID="itemList"]/body/row[itemID=1996||itemName=Sugar||2]/col[fieldName=SKU||1] 
(from http://www.jroller.com/sjivan/entry/smart_gwt_2_2_released)

David Gao, please reach out to Simeon on your return next week.

so looking at that, what if the scLocator=//IButton[ID=\"LocatableIButton_Next\"]/  ... was instead something like scLocator=//IButton[ID=\" LocatableDynamicForm?_GroupCreate_LocatableIButton_Next\"]/  which correctly included the parent hierarchy?

Does this help better define the repeatable hierarchical naming for QE's needs?

This is fine as long as it's possible to drill down from element to element multiple times. Another word, if it's feasible to construct something like:

scLocator=//IButton[ID=\"LocatableDynamicForm[ID=\"InventoryPanel\"]?_GroupCreate_LocatableIButton_Next\"]/

While the ordering of element is confusing, the above scLocator will prove the ability to go from element to element to element.

Once this feature is in place, it should be easy for QE to construct locator strategy to identify and perform actions on elements in the UI.

Started looking into what it will take to put more hierarchy information into the scLocator ids for the example provided. Will update case notes after connecting with Jay Shaughnessy.

Fixed numerous scLocator hierarchy issues with the following two commits to master available in successful builds >= 937:
62953e448515945c0dcb660ed46e67bdd0f6a617
cc05acd3b90f8f437977cf3eff1743978b00f7b2

The parent identifier should be reliably inserted into child buttons(ex. Next, Cancel,etc).  

David you will notice that some of the identifiers will have changed because of this change. 

The scLocator mechanism is the suggested approach of reliably identifying elements. XPath and related concatenation searches has been deemed unreliably brittle with the SmartGwt components. 

Please test out and comment on whether these changes provide QE with the reliable hierarchical naming that you were interested in or with more specific use cases where the current scLocator strategy is deemed insufficient.

spoke with dgao on 4/15 on this.  the current solution is not ideal, but qa is not blocked.  i will open new bugs on specific testability issues with selenium and the scLocators.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.