Last modified: 2012-03-26 18:10:09 UTC
Currently the "format = min" and "format = max" results formats only work with properties with '[[Has type::Number]]'. It seems reasonable for at least these two math-type formats to also work with dates, strings, pages, coordinates, etc., etc. The following page shows an example of the format failing to produce any output (not even a friendly warning) when being called on a non numeric format: http://scratchpad.referata.com/wiki/SRF_format_min_test I'm getting round this by using the array extension and a horrible hack ;-) Cheers, Dan.
Removing Denny as assignee. Dan, why would you want to be able to do this? I can see the use for max and min date/times, but think separate "earliest" and "latest" formats would be more appropriate for those. For the other formats, I really fail to see how having such functions would be useful. What would be a meaningful way to compute the max of a string? Sure you can find way to quantify it, but I doubt they'd be meaningful in more then a few esoteric contexts...
Created attachment 10322 [details] Adds two new formats, earliest and latest
Applied modified patch in r114481 :) Stuff that should still be fixed up: * The default value is "default"?? That's rather odd. An empty string would make more sense * Still need to add the messages for the printer name (ie srf_printername_earliest and srf_printername_latest), see https://www.mediawiki.org/wiki/Localisation
I don't think min(string) is too esoteric, but perhaps that's me. I thought the calculation was self evident, min = first in alphabetic descending sort order, max = opposite, just like in SQL. I don't see why we should proliferate type specific formats over making the existing formats type agnostic. OK, earliest and latest make for good aliases, but really, is min(date) so confusing? Perhaps I'm not getting something, or perhaps working with SQL has colored my perception, but I don't see the problem here. Cheers, Dan.
Created attachment 10328 [details] Adds msgs and sets default='' I just forgot to send the patch for msgs and [default]=default was done for my own debugging, corrected in this new patch :)
Great, I applied this in r114486 :)
Dan - I had the same thought as you did, but then I talked to Jeroen about it, and he convinced me that "earliest" and "latest" are better. There doesn't seem to be a real chance that "min" and "max" functions would be used for anything other than numbers (including values with units) and dates. Given that, it's just cleaner to have all the "math" formats, including min and max, be numbers-only - I think it's simpler for both creating queries, and for the code itself.
