[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    spinner component
From:       alexandre.iline () oracle ! com (Alexandre (Shura) Iline)
Date:       2011-12-28 6:26:46
Message-ID: 4EFAB6A6.6040305 () oracle ! com
[Download RAW message or body]



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:
>>> @Shura:
>>>
>>> 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 
an application.

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.
>
>>> (or
>>> 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.

Shura.


> 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
> February.
>
> I hope that clarifies things (if they needed any further clarification!)
> :-)
> -- Jonathan

[prev in list] [next in list] [prev in thread] [next in thread]