spinner component

[Daniel Zwolenski]

Just exploring the index thing a little more - could we have both the index
and the value as a type parameter?

So we have something like (just going for the gist of it, obvious cleanups,
possible use of callbacks, etc needed):

Spinner<Integer, String> spinner = new Spinner<Integer, String>();
spinner.setValueProvider(new SpinnerValueProvider<Integer, String> {
     boolean hasNext(Integer current) { return current <
myListOfValues.size() - 1; }
     Integer getNext(Integer current) { return current + 1; }
     boolean hasPrev(Integer current) { return current > 0; }
     Integer getPrevious(Integer current) { return current + 1; }
     String getValueFor(Integer index) { return myListOfValues.get(index); }
});

Then if you wanted to use an enum as the 'index' or an Int or a BigInt you
could?

e.g.

Spinner<TypeOfSport, Sport> spinner = new Spinner<TypeOfSport, Sport>();
spinner.setValueProvider(new SpinnerValueProvider<TypeOfSport, Sport> {
     boolean hasNext(TypeOfSport current) { return current.ordinal() <
TypeOfSport.values().length - 1;}
     TypeOfSport  getNext(TypeOfSport  current) { return
TypeOfSport.values()[current.ordinal() - 1]; }
     boolean hasPrev(TypeOfSport  current) { return current > 0; }
     TypeOfSport  getPrevious(TypeOfSport  current) {
        return TypeOfSport.values()[current.ordinal() + 1];  }
     Sport getValueFor(TypeOfSport  type) { return (create sport for type,
e.g. look up from map) }
});

We could then provide a suite of default providers (Number, List, Enum,
LinkedList, Calendar, etc). The provider could be what has the 'cycle' flag
on it too. So a List 'cycle' could implement the default logic for that
(i.e. the cycle becomes more of a provider issue).

Just thinking out loud really.


On Sat, Dec 17, 2011 at 9:26 PM, Tom Eugelink <tbee at tbee.org> wrote:

>
>
>
>> In essence, this approach is a one-method Callback<Integer, T> 'data
>> provider', where the method is 'public T call(Integer index)'. It is a
>> simpler data provider than what you mention. I guess my question is whether
>> the additional API is required? Also, in my opinion, I think Integer,
>> rather than BigInteger, is likely sufficient - but this isn't a major issue
>> for me right now.
>>
>
>
> I understand and am curious if it matches all that I needed. Basically
> what you see in my DataProvider API is what I needed while implementing the
> spinner:
> - is there a next value? (I generalized that to "give me the idx of the
> next value", which allows for some additional dynamics.)
> - is there a previous value? (dito)
> - what is the value for idx X?
> - what is the idx of value X?
>
> Now, thinking about, this multiple times the same value in the domain may
> be an issue for the last one.
>
> Tom
>
>
>