Alexandre (Shura) Iline
alexandre.iline at oracle.com
Tue Dec 27 22:26:46 PST 2011
On 12/28/2011 01:01 AM, Jonathan Giles wrote:
> On 28/12/2011 1:49 a.m., Alexandre (Shura) Iline wrote:
>> On 12/27/2011 01:51 AM, Jonathan Giles wrote:
>>> This was discussed earlier in the thread. If you joined the mailing list
>>> only recently you may have missed this discussion. Essentially, the
>>> thinking is that there is a form of 'data provider' that encapsulates
>>> the functionality to step between values, and that can also convert
>>> String input into an Object that can be understood and subsequently
>>> stepped from.
>>> So yes, there is likely to be a form of wrapping. Whether this is done
>>> by the developer explicitly setting an '(Enumeration | List | Integer |
>>> Float | Boolean | etc)DataProvider' into a Spinner.setDataProvider(..)
>>> method, or whether we have EnumerationSpinner, etc, hasn't been
>>> discussed. I'd lean towards the former however, but I'm only saying that
>>> as it is the way we tend to provide similar functionality (e.g.
>>> pre-built cell factories, pre-build string converters, etc).
>> When should I expect the spec to be updated with this?
> This kind of detail doesn't fit in the UX Specification documentation
> that Jindra writes. I think that, as with all UI controls, the
> combination of the UX Specification and the API documentation is the
> spec. I'm not sure that Tom is publishing his API documentation anywhere
> yet, but if he needs a place to host it I can help.
From where I sit, any information on how control would look like is
rather useless without information of how one can use the component in
If you are separating the two parts, fine. I still need the API spec.
After all it is the API which an app developer (and test developer) will
be communicating through.
> If the UI controls team needs to start generating more formal specs then
> hopefully this is something that SQE can bring up with the UI controls
> team to let us know what you need.
>>> by having the string 'typed' in), then either call spinner.increment()
>>> or click on the 'increment' button, and assert that the value returned
>>> by spinner.getValue() is "March".
>> That is what most of the tests will do - play with the button and
>> verify the value displayed.
>> Similar functionality needed for testing apps which use spinner - to
>> be able to scroll (by mouse clicks) to a desired value.
>> For that I need to know what value to expect and which way to scroll -
>> hence my question.
> It's not clear to me whether I've answered your question
There could be no complete answer really until the API is known.
I will wait for the spec.
> or not based on
> what you say above, so I'll try to answer again just in case. In the
> case of automated tests, you'll be instantiating a Spinner control, and
> as part of that you'll be setting a data provider. Based on the data
> provider you set, you can easily infer what the next value should be
> based on a current value (or index). For example, if you set a Month
> enum as that data provider, you know what month comes before and after
> I hope that clarifies things (if they needed any further clarification!)
> -- Jonathan
More information about the openjfx-dev