PDA

View Full Version : Ext.data.Store locale dependent sorting?



jsakalos
20 Apr 2007, 1:27 PM
Is locale dependent sorting of data store items implemented somehow?

Now it puts all texts starting with a local characters such as

jsakalos
12 May 2007, 10:19 AM
No idea?

dfenwick
12 May 2007, 12:03 PM
Without overriding Ext.Store.applySort() it will always do a simple comparison. The function used for comparison with the MixedCollection object that holds the records is created per sort, is private, and does only a less than, greater than, or equal to comparison.

When you override applySort(), you could then provide your own comparison function in your store (as a property) and check if it exists before using the regular one. For your strings, you'll probably want to use String.localeCompare() as the comparison function. Here's a quickie implementation that might suit your needs:


Ext.apply(Ext.data.Store.prototype, {
applySort : function(){
if(this.sortInfo && !this.remoteSort){
var s = this.sortInfo, f = s.field;
var st = this.fields.get(f).sortType;
var fn = this.fields.get(f).sortFunction || function(r1, r2){
var v1 = st(r1.data[f]), v2 = st(r2.data[f]);
return v1 > v2 ? 1 : (v1 < v2 ? -1 : 0);
};
this.data.sort(s.direction, fn);
if(this.snapshot && this.snapshot != this.data){
this.snapshot.sort(s.direction, fn);
}
}
}
});

At this point, in the record definition for your reader in the ds you can apply this (this is my ArrayReader object from my grid performance test code) - note the addition of the sortFunction property:


reader: new Ext.data.ArrayReader({}, [
{name: 'ip', type: 'string', sortFunction : ipSort},
{name: 'dns', type: 'string'},
{name: 'vendor', type: 'string'},
{name: 'os', type: 'string'},
{name: 'a', type: 'string'},
{name: 'b', type: 'string'},
{name: 'c', type: 'string'},
{name: 'd', type: 'string'},
{name: 'os_ver', type: 'string'}
])


And the function ipSort:


function ipSort(v1,v2) {
var ip1 = v1.data['ip'].split('.'), ip2 = v2.data['ip'].split('.');
var retval;
for(var i = 0, len = ip1.length; i < len; i++) {
var ip1octet = parseInt(ip1[i]);
var ip2octet = parseInt(ip2[i]);
if(ip1octet < ip2octet)
return(-1);
else if(ip1octet > ip2octet)
return(1);
}
return(0);
}


In your case, instead of doing the IP sorting calculation that I've done, you can pull in the strings for the field of interest and do something like this:


function localeSort(v1,v2) {
var st1 = v1.data['name'], st2 = v2.data['name'];
return(st1.localeCompare(st2));
}

The ability to provide your own sort function should really be rolled into the applySort() function. When Jack gets back from the oblivion we call having a new baby, I'll talk to him about getting it added into SVN.

tryanDLS
12 May 2007, 12:06 PM
Unless you tell it otherwise it's doing sorting based on Javascript's natural sort. You can provide your own SortType class to do comparisons differently.

jsakalos
12 May 2007, 12:31 PM
Thank you both for your answers; they give me the basic idea of the current state of the sort implementation.

Are there any plans to include localized sorts (at least framework for them) in any near or distant future?

By framework I mean something similar to translations where the app is developed as usual and then a single local file translates required strings. For sort it could be just the list of local characters in the proper order.

As of now this is not make/break feature in the app I'm developing but I'll have to solve it sooner or later. Just pondering if rather to wait or if to implement dfenwick's proposal.

dfenwick
12 May 2007, 12:39 PM
Thank you both for your answers; they give me the basic idea of the current state of the sort implementation.

Are there any plans to include localized sorts (at least framework for them) in any near or distant future?

By framework I mean something similar to translations where the app is developed as usual and then a single local file translates required strings. For sort it could be just the list of local characters in the proper order.

As of now this is not make/break feature in the app I'm developing but I'll have to solve it sooner or later. Just pondering if rather to wait or if to implement dfenwick's proposal.

Ext isn't internationalized. A lot of the static strings in the objects have been removed and moved into the localization areas in order to provide language-specific things, but it's not (and I don't think it's going to be) internationalized. However I will attempt to get applySort updated in SVN with the function I provided. That allows anyone to provide their own comparison callback. It probably should have been in there since the beginning. I'm sure it's just an oversight.

Technically you should probably override the sort() method of Store, since it's the public interface. However I know applySort() is called elsewhere in the Store, so that's why I overrode it. It's marked as a private function in the object, so I'll try to get Jack to add the user-defined callback function to it. It's a pretty simple change.

I'd recommend using what I provided until there's a public change available. If you're not a premium member, you'll have to wait until it gets released though.

dfenwick
12 May 2007, 12:41 PM
Unless you tell it otherwise it's doing sorting based on Javascript's natural sort. You can provide your own SortType class to do comparisons differently.

Just for reference, the sortType doesn't really affect things much. It just alters what type the data eventually ends up as prior to sending it to the sort function. For locale strings, it wouldn't help much since they're just strings from Javascript's perspective.

jsakalos
12 May 2007, 12:54 PM
Thank you, dfenwick (http://extjs.com/forum/member.php?u=22), very much.

You've done more than I expected especially in the effort to provide for future internationalization efforts.

You see, I understand that team cannot provide internationalization if Ext is going to be ready and functional in a reasonable time. What I'm calling for is to provide a "hook" where Ext public could hang their individual localizations.

This is also very important from the marketing point of view as to ignore internationalization means depriving ourselves of 80% of the worldwide market. (no idea if number is correct ;))

Thanks again,
Jozef