Menu
▾
▴
seleniumflexapi-development — The development mailing list for the Selenium-Flex API
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
|---|
|
From: Nikhil M <nmp...@gm...> - 2009-10-09 04:27:29
|
I don't think anyone particularly cares about the urgency of a nightly build at this time in the product life cycle. Weekly/two weekly should be fine. Rather than these extraneous matters, use the development resources available to focus on the core product. Resolve the key issues, which are (1) object recognition (2) method quality and reliability (3) documentation. Nikhil On Tue, Oct 6, 2009 at 10:14 PM, Fergal Hanley <fer...@gm...> wrote: > Nikhil, > I'd like to introduce you to Mohamed, aka Ed. I've asked him to help out on > the project here. He's a an ex-colleague from Silicon Graphics and located > in Melbourne as well. He's new to ActionScript but he's very technical and I > don't doubt he could pick it up in a jiffy. > Anyway, we were at lunch and I suggested that he could come up with the > automated build system. With that in place we'll be able to provide the > testers with a nightly build. We may also tie in our documentation > generation into the build loop as well, which will automatically deploy to > the website. > Anyway I think process improvement and streamlining is important for getting > the project to that next level. > Fergal |
|
From: Fergal H. <fer...@gm...> - 2009-10-07 05:14:59
|
Nikhil, I'd like to introduce you to Mohamed, aka Ed. I've asked him to help out on the project here. He's a an ex-colleague from Silicon Graphics and located in Melbourne as well. He's new to ActionScript but he's very technical and I don't doubt he could pick it up in a jiffy. Anyway, we were at lunch and I suggested that he could come up with the automated build system. With that in place we'll be able to provide the testers with a nightly build. We may also tie in our documentation generation into the build loop as well, which will automatically deploy to the website. Anyway I think process improvement and streamlining is important for getting the project to that next level. Fergal |
|
From: Fergal H. <fer...@gm...> - 2009-10-04 07:49:30
|
Hi Everyone, As part of our project revitalization, we have a much welcomed and needed addition to project management. I’d like to welcome on board Nikhil as our new Project Manager. Nikhil and I have been working together on the project for the last few months. Nikhil will take on the job of managing tasks, personnel and contributing to project community as a whole. This addition will enable me to have a completely focused technical role on improving and expanding the API. I would also like to welcome Colin, Slaven and Daren who have just recently, kindly offered to help on the project. We’ll soon be organising around you guys can help. We’ll need to added you to the project in the capacity you like to be in. Nikhil will be in contact with you about how you can help. We’d like to start using the facilities provided by Sourceforge a little more. The tracking facilities in Sourceforge should be more that adequate. You have a look at it here: https://sourceforge.net/tracker/?group_id=228427 We’ll use this as our nexus point for all activities going on in the project so everyone has visibility. It also has the advantage of pushing up the stats for the project on Sourceforge which will improve our rank, which is always nice. I’d also like to convince everyone to use this mailing list when communicating with other members of the project (unless you have a good reason not to). Please CC this list as much as possible. Regards, Fergal |
|
From: Fergal H. <fer...@gm...> - 2009-10-02 07:07:51
|
Hi Everyone, I want to revitalize the Selenium Flex API project. I've been fairly busy with another project at work over the past few months so I've neglected the API and it's starting to wane. I'd like to do a big push and get a few releases out over the next few weeks, capped with a release of 3.0 before Christmas which will include the ability to record scripts (which I've found the technical solution to). Simply put, I've found in the past, I need help on this project. Otherwise I'll work my ass of for a few weeks and run out of steam just to get a single release out. I'd like to get the project to a state where it has a few people regularly contributing to various different aspects of it, so that it's kept humming over and gradually grows in size and increases in quality. I think some important goals are to have regular releases, perhaps as many as once a month, a forum that provides quick feedback, but most importantly stability of the API and good up-to-date documentation online. Since you've had enough interest in the project to subscribe to the development mailing list I'd like to invite you to take a role on this project. Obviously the more time someone is willing to commit, the better, but even a small commitment would be appreciated. I've identified the following roles that need to be filled. I'm hoping one person will take the lead on each of these areas: - Document writers: We need at least one person to write up and publish all documentation for the API. The will involve writing tutorials, articles and keeping on top of developers and testers to keep the reference material up-to-date. - Website editor: We need at least one person to carry out development and administration of the project website. They'll be responsible for pretty much everything that goes on, on the sourceforege site. It's not a huge site so this is a fairly manageable task for one person. - Testers: The more the better frankly. Currently there is only a very flimsy test process for the api. We need individuals to setup and execute test cases on the API. Ideally they'd use the existing infrastructure of the sourceforge site but this is reall down to whoever takes the lead on this. - Developers: We need more developers to help improve the current code and develop new features to be added. You'll need to be familiar with ActionScript. My role in this will be as a general project manager/developer/release manager. I'd really appreciate if you could help out in one or more of these areas. I've found that this project is quite satisfying to work on once it gets moving and I'm ping we can have some kind of community spirit emerging from it. Please contact this mailing list if your interested, or if you'd prefer contact me directly at fer...@gm.... I'd like to keep the project small and we should all use this mailing list for project communications. This will keep everyone in the loop with whats going on and hopefully we can get this thing snow balling. If it gets bigger and to much to handle we can have mailing lists for the different aspects of the project but for now I'd like to keep it all together. Hoping to hear from you soon, Fergal |
|
From: Fergal H. <fer...@gm...> - 2009-06-24 23:32:22
|
Hi Steve, In regards to the point of confusion, the object should exist so long as the data binding to the MenuBar is updated before clicking the first menu. If clicking on the first menu is what triggers the dataProvider source object to be populated then the object won't exist until that happens. Answers below for your other questions: On Thu, Jun 25, 2009 at 8:19 AM, Booth, Steve <ste...@hp...> wrote: > Hi Fergal, > > I've asked my management for approval to share what I have. I should get a > response within 2 days. > > In the meantime, I'm confused about one of your responses (I commented your > email, below). > > I've also forwarded your email to my team, with hope there is sufficient > interest to get people onto the developers email list. We're still > wrestling with several problems, and some interaction would seem warranted: > > - we haven't yet had success navigating a 'tree' (expanding '+' > buttons, collapsing '-' buttons, etc) > > There needs to better support for tree components in the API. Something we're taking on for the next release which should be out in about 2 weeks > > - > - we're trying to establish a good generic way to access UI components > that might exist in the header of a DataGrid (e.g., like a checkbox to > select "all" datagrid rows) [i.e., we're pretty much novices over here] > > There's a bug in the API that sometimes prevents interaction with objects embedded in other components. We're looking into this currently and will have a fix in the next release. Have you tried running the refreshIDTooltips command to see if the id can be located on the component? > > - > - non-unique IDs; we haven't yet deciphered how to uniquely scope > objects that have the same ID; the AppTreeParser code seems to support the > "/" character for scoping, we just have to figure out how to use it properly > > There are 2 main ways to uniquely identify objects with the same id: 1. using the "/" this is done by specifying a unique container component to narrow the search scope to that; followed by the id of the target component. For example myCanvas/myButton - this method is the most stable in terms of coping with changes on the UI. 2. using index for example myButton[3] - this is less stable as it can be hard to predict what index will be allocated to the component which can easily happen if the component are created in a different order for different test scenarios. > - > > Thanks for the information you sent us, and I'll let you know as soon as I > hear from the management. > > Steve > > > ------------------------------ > *From:* Fergal Hanley [mailto:fer...@gm...] > *Sent:* Tuesday, June 23, 2009 6:45 PM > *To:* Booth, Steve > *Cc:* Scott Galloway (sbg...@gm...); > sel...@li... > *Subject:* Re: Flex Selenium > > Hi Steve, > > Aswers and questions below: > > On Thu, Jun 18, 2009 at 2:36 AM, Booth, Steve <ste...@hp...>wrote: > >> >> ... stuff deleted ... >> >> It seems to me that some external influence might be necessary to deal >> with a cascading menu bar. An existing method, clickMenuBarUIComponent, >> works with a single menu cascade, but not for 2 or more. >> >> I'm new to this, so please bear with me. Given the (apparent) >> single-threaded nature of what I see in the ".as" files, it seems that after >> the first menu item is found, we need to allow a repaint to occur between >> each subsequent menu cascade. Only with the repaint will we find a >> populated MenuBarItem. >> >> ... stuff deleted ... >> > > The MenuItem object exists and is clickable even before a repaint occurs. > For example if you gave your MenuItem an id then you could just use the > flexClick command to directly click it without having to navigate the menu > and wait for cascade. That said I think this isn't the way tests should be > performed that require clicking menu items. > > Point of confusion: Suppose the MenuBar component is used to create > MenuItems in a data-driven manner, using the dataProvider property. Then > the MenuItem objects don't exist (yet), do they? > |
|
From: Fergal H. <fer...@gm...> - 2009-06-24 01:11:29
|
Hi Steve, Aswers and questions below: On Thu, Jun 18, 2009 at 2:36 AM, Booth, Steve <ste...@hp...> wrote: > > Hello Fergal and Scott, > > Jason Fountain, with whom you've exchanged email recently, has been working > with my team on a Flex/Selenium project. > > I'd like to follow up with a question or two, and hope you can spare time > to reply. > > It seems to me that some external influence might be necessary to deal with > a cascading menu bar. An existing method, clickMenuBarUIComponent, works > with a single menu cascade, but not for 2 or more. > > I'm new to this, so please bear with me. Given the (apparent) > single-threaded nature of what I see in the ".as" files, it seems that after > the first menu item is found, we need to allow a repaint to occur between > each subsequent menu cascade. Only with the repaint will we find a > populated MenuBarItem. > > If that is a correct understanding of the beast, then I am willing to share > some code I wrote, with approval from my management. What I have works for > us - the question is whether the approach is sufficiently generalized for > the global community. > The MenuItem object exists and is clickable even before a repaint occurs. For example if you gave your MenuItem an id then you could just use the flexClick command to directly click it without having to navigate the menu and wait for cascade. That said I think this isn't the way tests should be performed that require clicking menu items. > So, here are the questions: > > Q1: Is it generally true that a repaint is necessary for each subsequent > menu cascade? [Note: We have a proprietary way to short-circuit this, but > I'm trying to establish a "general use" behavior] > Repaint is not necessary but ideally a repaint should occur as to model user interaction. Any departure from this and your getting into unit-test territory of which there are better solutions than the Selenium Flex API. Could you explain a little more about your proprietary solution? > > Q2: Within the design constraints you have for your Flex/Selenium work, is > it OK to expect users to poll for a "menu sequence done" condition, after > making a call to initiate the sequence? > I've proposed earlier a new method for navigating menus whereby the tester enters an address string for the MenuItem they want to click and the waiting between repaints is handled by the API *internally* and is based on the delay setting for the component. For example such a command would look like: Command: flexClickMenuItem Target: myMenu1~mySubMenu~myMenuItem1 Value: Trying to directly click the menuitem would throw an error. And if the MenuItem was in a radio group or checkable Command: flexSetMenuItem Target: myMenu1~mySubMenu~myMenuItemSelection1 Value: true I propose using the Tilda to delimit the menuItems because we want to reserve the dot for supporting fully qualified names in the target parameter (a feature to be added soon). Anyway, thanks for your interest in the project Steve. I hope I could answer questions appropriately. Has there been much interest in this project over there at HP? If you guys want to get more involved then get onto the developers mailing list. The project is going to go through a phase of high activity over the next few weeks so it might be fun to get in on it. Thanks, Fergal > > Thanks for your time, > Steve Booth |
2 messages has been excluded from this view by a project administrator.
