RE: How to change the order of repeat-items?

Hey, that's a really neat thought!

I'd previously felt that we would do data sorting by an action
rather than an extension function because none of our other 
functions have these kinds of side effects (XPath engines
aren't even guaranteed to have write access to the DOM).

So, I was quite on board when you said use an action, but to
have a separate action that could set a UI layer sorting 
property of a repeat or itemset is quite a nice idea.

We already have UI layer state information and actions that
manipulate the information, e.g. switch and toggle, repeat
and setindex, so the precedent is there.  And we already have
the issue of solving this state information problem in the
iteration case, such as managing the repeat index for each
instantiation of a repeat that is iterated by a containing repeat.

Having a whole action will lead to more configurability, and
I think the amount of configuration will be unavoidable, e.g.
how to set up secondary keys and how to set up different kinds of
comparisons such as numeric, lexicographic, ascending/descending.
Or maybe just how to define the comparison function to be used,
which would solve all of the above.

Cheers,
John


-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
Behalf Of T. V. Raman
Sent: Monday, April 18, 2005 12:43 PM
To: mark.birbeck@x-port.net
Cc: tvraman@almaden.ibm.com; Leigh.Klotz@xerox.com;
suzan.foster@nerocmediaware.nl; www-forms@w3.org
Subject: RE: How to change the order of repeat-items?




Mark -- I wasn't clear in my earlier note.
I wasn't pushing back on sort in the UI layer; I was pushing back
on the idea of doing it with simple attrs on the UI construct
because I think that appraoch (i.e. attrs) will not have enough
expressive power.


>>>>> "Mark" == Mark Birbeck <mark.birbeck@x-port.net> writes:
    Mark> 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.
    Mark> 
    Mark> I disagree ;)
    Mark> 
    Mark> As you know -- since you are a strong advocate for it
    Mark> -- there are many situations where the UI does not
    Mark> *directly* reflect the model. For example, take
    Mark> xf:select1; its purpose is for the user to choose an
    Mark> item from a list, but it is possible for the list to
    Mark> not be 'in view', even though the list is obviously in
    Mark> the model. The list might be limited because the author
    Mark> has used:
    Mark> 
    Mark>   @appearance="minimal"
    Mark> 
    Mark> or it might be limited because the user has collapsed a
    Mark> node in a tree, or whatever.
    Mark> 
    Mark> Other examples would be the use of date pickers to both
    Mark> select and render dates, check-boxes that look nothing
    Mark> like the word 'true' or 'false', colour pickers that
    Mark> obviously don't look like #ab7f34, a number like "100"
    Mark> stored in the model but rendered as "$100.00", and so
    Mark> on.
    Mark> 
    Mark> So, my view is that *some* (not all) of the use cases
    Mark> for sorting fall into this domain -- the user might be
    Mark> able to control them and the author might be able to
    Mark> hint at them, but either way, the model doesn't
    Mark> care. (To put it in terms of the MVC architecture, we
    Mark> are simply allowing the creation of an ordered 'view'
    Mark> of a set of nodes, without touching the underlying
    Mark> nodes.)
    Mark> 
    Mark> 
    Mark> I would say that the sortable columns of email or
    Mark> contacts falls into the category of a 'user sort' --
    Mark> this can be done with no mark-up at all, since it's
    Mark> just a more complex version of the button next to a
    Mark> drop-box that shows you the list of options, and is not
    Mark> under the control of XForms, but under the control of
    Mark> the user agent.
    Mark> 
    Mark> In the category of an 'author-hint sort' would be the
    Mark> rendering of the selections in a selection list; the
    Mark> names of the countries would be in one order in one
    Mark> language, and in another order in another language, for
    Mark> example.
    Mark> 
    Mark> And in the category of a 'model sort' might be the list
    Mark> of items in a flowchart, since in this case the order
    Mark> in the model really does matter.
    Mark> 
    Mark> The 'model sort' is more accurately a proper
    Mark> re-ordering of nodes, that should be permanent, and
    Mark> would therefore be achieved through an action or
    Mark> extension function. The second one is more like a
    Mark> 'filter' -- a different 'view' on the same underlying
    Mark> nodes, but with those nodes left completely intact.
    Mark> 
    Mark> Regards,
    Mark> 
    Mark> Mark
    Mark> 
    Mark> 
    Mark> Mark Birbeck CEO x-port.net Ltd.
    Mark> 
    Mark> e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w:
    Mark> http://www.formsPlayer.com/ b:
    Mark> http://internet-apps.blogspot.com/
    Mark> 
    Mark> Download our XForms processor from
    Mark> http://www.formsPlayer.com/
    Mark> 
    Mark> 

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    RDC --- Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://almaden.ibm.com/u/tvraman      (google:raman+labrador)
AIM:      emacspeak
GPG:          http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Monday, 18 April 2005 20:47:03 UTC