API Review request for RT-19375 Pagination UI Control

[Richard Bair]

I'm still not sold on the arrowVisible property. The main issue being that whether the arrows show or not might be skin specific or situation specific rather than something that is either on or off.

I know you guys had a powwow today to iron things out, did this proposal change at all?

Richard

On May 8, 2012, at 6:46 PM, Jonathan Giles <jonathan.giles at oracle.com> wrote:

> 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