Consistency in command parameters

[Yugang]

Hi, guys,

Currently we are seeing some inconsistencies between commands and
command interfaces:

1. Some flex commands take 1 parameter, some take 2 and some take 3
parameters.
What do you think about making all the getFlex command interfaces
consistent by taking 2 parameters so that we can always use verifyFlex
commands in Selenium IDE? Currently you can NOT use verifyFlex if the
getFlex command does not take 2 parameters.
Should we force all commands even for doFlex to take 2 parameters if
we expose them via Commands?

2. Some commands require additional values to be in target while
others take everything else from value.
For example, some commands have the following interface:
target: <DataGridId>, <Row>, <Column>
value: <Data>
While others take the following:
target: <DataGridId>
value: <Row>, <Column>, <Data>

Thanks,

Yugang

[Fergal Hanley]

Yes we need to improve consistancy on the command interfaces. I was
thinking that we should provide two different types of interfaces. One
type for the selenium IDE that accepts two params and another type
that can accept multiple params that can be utilized by more advanced
users by their respective test frameworks.

[Yugang Hu]

I see. Any kind of naming convention do you want to differentiate the
two interfaces?

Couple other questions:
1. Where do you guys want to put ASDocs?
2. Should we expose a java library (jar) to include the files under
http://code.google.com/p/sfapi/source/browse/#svn/trunk/test/SelFlexDemoTest/src/net/sourceforge/seleniumflexapi?

Thanks.

On Tue, Jul 13, 2010 at 4:53 PM, Fergal Hanley <fergal...@gmail.com> wrote:
> Yes we need to improve consistency on the command interfaces. I was thinking

[Fergal Hanley]

1. Do you think it would be possible to get the AsDocs up on the wiki. If not we can put them on a google-sites website and link to it from the project home page. Either way I think they should be online so that they can be updated to match the trunk. We should have some sort of automated process for generating the AsDoc, perhaps as part of a CI loop. I'm looking at getting a server at the moment and will want to get Hudson up on it. For each release we may want to have a separate set of AsDocs that get packaged perhaps with the release itself.

2. Yes I think it's very important to have a jar for those Java classes. We need to provide users with an easy to use method for integration with their test frameworks. We should provide a maven repo for the jar as well. At the moment I'm using our SVN to host the repo. I don't think there's any issue with using SVN for this purpose so I guess we'll keep doing it.

Cheers,

Fergal

[Selenium Tester]