I'm just thinking out loud, but what if we added a getSorts() to avoid 
incompatibility issues? 

        public List<SortParam> getSorts() {
                return state.getSorts();
        }

        public SortParam getSort() {
                return (state.getSorts().isEmpty()) ? null : 
state.getSorts().get(0);
        }

-----Original Message-----
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:34 AM
To: users@wicket.apache.org
Subject: Re: SingleSortState multiple sorts?


Yes, I too would prefer multisort to be in Wicket by default. It is much 
more logical for the sort to be "stable", i.e., it sorts the *current* 
list with respect to the new sort order, rather than the original list.

Especially when the original list is from the database and it is 
essentially undefined what order it is coming out (with respect to 
non-sort columns).

Problem is that it is an incompatible change and a hassle for the 
implementors of sortable data providers, because suddenly they need to 
take into account many sorts instead of only 1.

Regards,
Sebastiaan

Hoover, William wrote:
> It seems as though this would be a good candidate for a replacement for 
> SingleSortState/SortableDataProvider. We really don't need the single sort 
> version if we have a multiple sort version (reduce bloat ;o)?
> 
> -----Original Message-----
> From: Hoover, William [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 21, 2008 9:23 AM
> To: users@wicket.apache.org
> Subject: RE: SingleSortState multiple sorts?
> 
> 
> Ironically, your code looks very similar to what I have done on my end. Can 
> we create a feature request for this?
> 
> -----Original Message-----
> From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 21, 2008 9:13 AM
> To: users@wicket.apache.org
> Subject: Re: SingleSortState multiple sorts?
> 
> 
> I wanted to have this the other day, so I came up with (see attached). 
> I'd like to see your ideas about it, since this was just a 20 minute 
> first hack...
> 
> IClusterable is just a tagging interface for the sole purpose of 
> clustering via Terracotta. So if you don't need TC, then Serializable 
> should be fine.
> 
> Regards,
> Sebastiaan
> 
> 
> Hoover, William wrote:
>> I was looking into providing a List<SortParam> in a ISortState/IClusterable 
>> (multiple version of SingleSortState) for a SortableDataProvider. Does the 
>> list within the sort state need to be IClusterable?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to