Re: [Seleniumflexapi-development] Flex Selenium

[Fergal H. <fer...@gm...>]

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