Igor is right in most cases. We do rely on the datastore to sort most of the time, which, when it works, is the proper way to go. The reason the issue comes up for us is that we may be sorting text data that changes from one locale to another, and hence needs to return a sort order that is unique for each Locale. For example, a field may consist of enumerated values, each of which has localized display text. Sorting would produce one result in English and another in German. The database doesn't have the localized strings at all, and it shouldn't. So in this case, we need to delay the sorting until after we've retrieved the data. Then we sort using a Locale-sensitive Comparator.
While sorting is most often done by the database, I don't think Wicket's design should assume this is where sorting will be done. Wicket should leave that up to the application developers. igor.vaynberg wrote: > > erm. what? > > you should be sorting your data inside the datastore that stores it. > eg if you are using the database you dont pull out all rows and sort > them in memory, you use the database to do the sorting. dont know what > kind of datastore you are using, but you are definetely doing > something funny. furthermore, there is nothing in wicket's design that > dictates how your application should be structured, how it should > access the datastore, or how it should do its sorting or any other > kind of data handling. > > -igor > > ----- There are 10 kinds of people: Those who know binary and those who don't. -- View this message in context: http://www.nabble.com/PropertyResolver-redesign-tp16495644p17137042.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
