API Review request for RT-19375 Pagination UI Control

[Jonathan Giles]

Hey Kinsley,

I presume there would also be a arrowVisibleProperty() as well?

Also, I'm guessing the upper-case M was used mistakenly for the 
MaxPageIndicatorCountProperty() method (and javadoc)?

-- Jonathan


On 9/05/2012 1:28 p.m., Kinsley Wong wrote:
> After talking to Jasper.  We would like to add these two method to 
> show or hide the arrow indicators.
>
> boolean isArrowsVisible()
> setArrowsVisible(boolean)
>
> Also we would like to rename the PageIndicatorCount property to 
> MaxPageIndicatorCount.  This is a better description the property.
>
>     /**
>      * The maximum number of page indicators to use for this 
> pagination control.  This
>      * value must be greater than or equal to 1.  The number of page 
> indicators will be
>      * reduced if MaxPageIndicatorCount cannot fit within this control.
>      *
>      * The default is 10 page indicators.
>      */
> public final IntegerProperty MaxPageIndicatorCountProperty()
>
>
> Kinsley
>
> On 4/25/2012 1:54 PM, Richard Bair wrote:
>> First off, although this API design is quite different than what I 
>> was initially expecting I think it is quite a bit better and more 
>> useful than what I had in mind. The API looks good to me.
>>
>>> I'd be keen to see the design docs too.
>> I've emailed Jindra to see if he can get the text&  images uploaded 
>> and public (can't attach things to email or I'd just send it.)
>>
>>> One thought: is the use of an integer index the best way to reference
>>> pages? Creates some possible complexities when pages are added and 
>>> removed.
>>> e.g. I want to jump to the 'details' tab, is this page 2 or 3? 
>>> Perhaps a
>>> generic 'ID value' would be useful, then the developer can use 
>>> integers,
>>> enums, strings or custom objects? I'm not sure either is best, just
>>> thinking out loud.
>> Personally I like the simplicity of the int. I think one of the 
>> differences between this and a TabPane is that it doesn't have names 
>> on pages. I'm thinking about, for example, search results with pages 
>> of data. Each page isn't closable. Pages are conceptually a serially 
>> stream that you pass through, rather than random access.
>>
>>> Interested why were animations assumed to be not included? Just for 
>>> effort
>>> saving, or some other reason?
>> I think just for the effort -- we want animations to be specified via 
>> CSS and it isn't all there yet. That said, I would fully expect the 
>> swipe based navigation to stay with your finger, so it animates. Just 
>> upping Kinsley's complexity factor a bit :-)
>>
>>> I'm very interested in the page virtualisation stuff. What are the 
>>> thoughts
>>> around this? The API uses a factory to create pages, but TabPane 
>>> does not.
>>> What's the rationale behind this difference (not complaining, just
>>> wondering)? How/when will this be called (e.g. each time a page is 
>>> shown,
>>> or the first time and then it is cached, etc)? If the tab changes 
>>> does the
>>> page get notified that it is active/inactive?
>> Ya, I found this interesting as well because originally I was 
>> thinking Pagination was just a simple TabPane subclass with a 
>> different skin. But I really like what they did, because it really is 
>> a different beast (see above). So it isn't meant to be such a thing 
>> that the user directly interacts with to "close" a page, for example. 
>> They re-run their query or something in order to change the content 
>> (assuming it isn't static content).
>>
>>> What happens if the factory returns the same instance of a 'page' 
>>> for two
>>> different tabs (is this allowed or an error)?
>> I'm not sure, good question. It seems like if you're going to get 
>> animated swipe like behavior then you will want to have two different 
>> nodes and then can just reuse them. But in any case I think it should 
>> be allowed to reuse node content between pages. Seems like for 
>> performance this would be a requirement on mobile / embedded devices.
>>
>>> Just thought of one thing with both TabPane and this - I'd like the 
>>> ability
>>> to prevent the user from leaving the current tab. In the case of form
>>> entering if the user has entered some dodgy data I'd like to prevent 
>>> them
>>> from changing tabs (e.g. intercept and consume the change tab event) 
>>> until
>>> they fix the data up. Is this possible, should I file a separate JIRA?
>> That's a great requirement. Is there a JIRA already for the tab 
>> requirement? We should definitely have that. It would be great to 
>> have some events when the user leaves a page too.
>>
>> Thanks!
>> Richard