On Tue, 27 Mar 2001, Dieter Maurer wrote:
Each "cmp" is looked up in the namespace and if not found there, in a standard set of comparison function, such that it is easy to get "locale_asc", "locale_desc", "case_insensitive_asc", ....
As I already said, this looks good... but I don't want to have a predefined set of names. Sad, because it would be difficult for non-Python programmers to define these functions.
Aha, I see the point!
What I suggest is an approach similar to the custom formats:
there is a predefined set of well known and often used sort function (such as "locale", "case_insensitive", ...) *BUT* a user can use a function of his own, too, if he likes.
Ok. Do you see any non-cmp functions beynd these "locale" and case_insensitive? :) I can't work out a good set of predefined functions. All those string, date, numeric comparisons - they are just cmp and nothing more.
real functions. And I don't want to have 2 almost identical functions (asc/desc) for every comparison function. So I am thinking about syntax like this:
sort="attr1/cmp1,attr2,attr3/cmp3/desc,...." To separate the direction is a good idea. I like it. I am not so sure about the '/' separators. I expect, we will soon get "/" separated object access paths.
Not in DTML - in ZPT, but it is different beast :)
Then, the use of "/" for a completely different purpose may be confusing. Not sure, that my "[...]" is better in this respect...
Hmm... sort="attr1[cmp1],attr2,attr3[cmp3:desc],...." or ...",attr3[cmp3/desc],..." or ...",attr3[cmp3,desc],..." Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.