- From: Klotz, Leigh <Leigh.Klotz@xerox.com>
- Date: Mon, 18 Apr 2005 13:36:50 -0700
- To: "Mark Birbeck" <mark.birbeck@x-port.net>, <tvraman@almaden.ibm.com>
- Cc: <suzan.foster@nerocmediaware.nl>, <www-forms@w3.org>
Mark's point about the controls presenting views on data is clear enough and I don't think anyone was disagreeing with that premise. I might agree with Raman's comment that simple attributes might not be enough, but I am not sure yet. I do note, though, that presenting sorting without author control brings up the question of what's being sorted; i.e., what is the sort key accessor function, and what is the comparator? There are many options, and I think that the ability to express the (needed) options from the list below will give a test of whether the simple attribute (or simple child element) case is good enough. 1. Sort key is label. - If I show a list of airport codes with city names as the labels, presumably I want to sort by city name, not by airport code. Otherwise we'll get complaints from all the Canadians about YOW and YYV appearning at the bottom of the list ;-) 2. Sort key is value - What if value is complex, in the case of select? 3. Sort key is some computed expression. - Useful in the above case of select1 and complex value. 4. Sort key is one of the above, but comparison function is elsehow specified. One possibility is to use the XML Schema type - Lexicographic ascending/descending (xsd:string) - Numeric or date-based ascending or descending -- (xsd:number, xsd:dateTime) - Other more complicated user-defined Schema types But then what if there's no Schema or the processor doesn't support it (XForms Basic)? Leigh. -----Original Message----- From: Mark Birbeck [mailto:mark.birbeck@x-port.net] Sent: Monday, April 18, 2005 11:26 AM To: tvraman@almaden.ibm.com Cc: Klotz, Leigh; suzan.foster@nerocmediaware.nl; www-forms@w3.org Subject: RE: How to change the order of repeat-items? Raman, > The idea of putting sort attrs on the ui layer is enticing, but I am > afraid it will run into a wall fairly quickly. I disagree ;) As you know -- since you are a strong advocate for it -- there are many situations where the UI does not *directly* reflect the model. For example, take xf:select1; its purpose is for the user to choose an item from a list, but it is possible for the list to not be 'in view', even though the list is obviously in the model. The list might be limited because the author has used: @appearance="minimal" or it might be limited because the user has collapsed a node in a tree, or whatever. Other examples would be the use of date pickers to both select and render dates, check-boxes that look nothing like the word 'true' or 'false', colour pickers that obviously don't look like #ab7f34, a number like "100" stored in the model but rendered as "$100.00", and so on. So, my view is that *some* (not all) of the use cases for sorting fall into this domain -- the user might be able to control them and the author might be able to hint at them, but either way, the model doesn't care. (To put it in terms of the MVC architecture, we are simply allowing the creation of an ordered 'view' of a set of nodes, without touching the underlying nodes.) I would say that the sortable columns of email or contacts falls into the category of a 'user sort' -- this can be done with no mark-up at all, since it's just a more complex version of the button next to a drop-box that shows you the list of options, and is not under the control of XForms, but under the control of the user agent. In the category of an 'author-hint sort' would be the rendering of the selections in a selection list; the names of the countries would be in one order in one language, and in another order in another language, for example. And in the category of a 'model sort' might be the list of items in a flowchart, since in this case the order in the model really does matter. The 'model sort' is more accurately a proper re-ordering of nodes, that should be permanent, and would therefore be achieved through an action or extension function. The second one is more like a 'filter' -- a different 'view' on the same underlying nodes, but with those nodes left completely intact. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Monday, 18 April 2005 20:37:18 UTC