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

the other way to think of this would be to view sort as an action
handler analogous to insert and delete.
You could then let sort  operate against the model. Doing this
would give the author a lot of flexibility by being able to
create different sort triggers that have different ordering
predicates on them.

The idea of putting sort attrs on the ui layer is enticing, but I
am afraid it will run into a wall fairly quickly.

>>>>> "Klotz," == Klotz, Leigh <Leigh.Klotz@xerox.com> writes:
    Klotz,> Sorting on the UI side for select1 makes a lot of
    Klotz,> sense and I have a use case for it.  I could go
    Klotz,> either way on repeat, though (model or UI).
    Klotz,> 
    Klotz,> Ben's suggestion of sort-key="@surname, @firstname"
    Klotz,> seems like a good start but I have two concerns:
    Klotz,> 1. Comma separated attribute list, even if space
    Klotz,> separated.  2. The sort keys and ordering are fixed
    Klotz,> and cannot be altered by UI operations.
    Klotz,> 
    Klotz,> As Raman points out below, most cases for sortable
    Klotz,> lists have multiple sort columns, allow them to be
    Klotz,> selected, and allow the ascending/descending sort to
    Klotz,> be specified by UI operations.  (Again, look at your
    Klotz,> mail reader.)
    Klotz,> 
    Klotz,> How about adding sort and orderby elements as
    Klotz,> children of itemset?  Then you can use @ref or @value
    Klotz,> on them to gain at least one level of indirection,
    Klotz,> and to fit in more harmoniously with the existing
    Klotz,> features of itemset.
    Klotz,> 
    Klotz,> <select ref="destination"> <itemset
    Klotz,> nodeset="instance('oag')/airports"> <label
    Klotz,> ref="@name" /> <value ref="." /> <sort ref="@name" />
    Klotz,> <orderby>ascending</orderby> </itemset> </select>
    Klotz,> 
    Klotz,> Unfortunately, that still provides only a single
    Klotz,> sort, and doesn't offer a way to describe to the UI
    Klotz,> the alternatives to choose from.  Might switch might
    Klotz,> come to the rescue here?  (Again, that seems
    Klotz,> problematic as it would be inside a repeating
    Klotz,> structure.)  Does anyone want to take it from here?
    Klotz,> (Sorry for the partly-baked idea.)
    Klotz,> 
    Klotz,> Leigh.
    Klotz,> 
    Klotz,> -----Original Message----- From: T. V. Raman
    Klotz,> [mailto:tvraman@us.ibm.com] Sent: Saturday, April 16,
    Klotz,> 2005 8:34 AM To: Ben.Atfield@x-port.net Cc:
    Klotz,> tvraman@almaden.ibm.com; Klotz, Leigh;
    Klotz,> suzan.foster@nerocmediaware.nl; www-forms@w3.org
    Klotz,> Subject: RE: How to change the order of repeat-items?
    Klotz,> 
    Klotz,> 
    Klotz,> 
    Klotz,> this is a good summary, Thanks.
    Klotz,> 
    Klotz,> I think we should think carefully about re-ordering
    Klotz,> on the UI side without sorting things in the data
    Klotz,> layer; there are pros and cons to doing that.
    Klotz,> 
    Klotz,> It would be simplest to keep the UI reflecting the
    Klotz,> stte of the data model, which is why I suggested
    Klotz,> sorting the data.
    Klotz,> 
    Klotz,> The XSLT route would also be easy to try in current
    Klotz,> browsers most of which support XSLT through the
    Klotz,> XSLTProc scripting function; incidentally this is
    Klotz,> what GoogleMaps uses in both IE and Mozilla, which is
    Klotz,> also one of the reasons GoogleMaps fails in
    Klotz,> back-level browsers like Opera that do not understand
    Klotz,> XPath, leave alone XSLT.
    Klotz,> 
    Klotz,> So as a first step in figuring out the use cases that
    Klotz,> we need to support, I'd suggest experimenting in IE
    Klotz,> Formsplayer and FireFox XForms by implementing the
    Klotz,> sort via XSLT called through XSLTProc to rearrange
    Klotz,> the nodes in the instance.
    Klotz,> 
    Klotz,> Here are some of the sort use cases I've seen on the
    Klotz,> Web today:
    Klotz,> 
    Klotz,> a) Phone bills; allow you to sort the list of calls
    Klotz,> according to various criteria
    Klotz,> 
    Klotz,> B) Shopping sites of course.
    Klotz,> 
    Klotz,> In general sort today shows up in grid layouts
    Klotz,> achieved via scripting, but a more interesting use
    Klotz,> case that doesn't show up on today's Web mostly due
    Klotz,> to the limitations of what has been possible is
    Klotz,> dynamic sorting of deeply nested structured data
    Klotz,> whereby things of interest bubble to to the top of
    Klotz,> the tree as the user specifies some input.
    Klotz,> 
    Klotz,> As an example, consider a collection of all airports
    Klotz,> in the world organized as a structured
    Klotz,> tree. Navigating this tree typically would take a
    Klotz,> sequence of interaction gestures to open up multiple
    Klotz,> levels of the tree.  You can implement nested tree
    Klotz,> navigation as has already been shown by Mark Birbeck
    Klotz,> in FormsPlayer; it would be interesting to first lash
    Klotz,> together the ability to sort the data nodes using
    Klotz,> XSLT --- and having that functionality in place,
    Klotz,> start doing some experimentation on the above tree
    Klotz,> navigation example to see if we could speed up task
    Klotz,> completion by sorting as the user types i.e. the
    Klotz,> equivalent of Emacs incremental search with the
    Klotz,> effect showing up on the display by the tree
    Klotz,> reforming itself to reflect the items to be most
    Klotz,> likely of interest.
    Klotz,> 
    Klotz,> The best thing about all this is that with what we
    Klotz,> have in place, a chunk of experimentation can be done
    Klotz,> before any spec writing.
    Klotz,> 
    >>>>>> "Ben" == Ben Atfield <Ben.Atfield@x-port.net> writes:
    Ben> Raman/Leigh/Suzan,
    >>> An interesting place to start this investigation would be
    >>> to see if exslt.org has already gone down this (x)path of
    >>> sorting nodes.
    Ben> 
    Ben> EXSLT.org wouldn't need to, since XSLT itself supports
    Ben> sorting. As Leigh says, though, the XSLT way, may be the
    Ben> model to look at (see later). First, it might be worth
    Ben> separating out where we want to do the sorting --
    Ben> establishing the use cases.
    Ben> 
    Ben> If we want a xf:repeat that behaves like a grid, and
    Ben> (for example) clicking on the heading of a column sorts
    Ben> by that column, this actually has nothing to do with the
    Ben> XForms model, and only relates to the UI. A UI could
    Ben> support this feature *now* without requiring any changes
    Ben> to XForms.
    Ben> 
    Ben> Similarly, if you want to sort the nodes in a nodeset --
    Ben> actually re-order them, not just render them differently
    Ben> -- then that can be achieved *now* with an extension
    Ben> function (most implementations support the definition of
    Ben> extra functions that are not part of the base spec).
    Ben> 
    Ben> Whilst these use cases can be done now, there are of
    Ben> course others that can't. The main one is where the
    Ben> *author* wants the UI to render data in a certain order,
    Ben> independently of how the user might interact with that
    Ben> data, and also independently of the order of the
    Ben> instance data.
    Ben> 
    Ben> The two situations where this might be the case would be
    Ben> the 'choices' in an xf:itemset (in xf:select1 and
    Ben> xf:select), and of course a list of items in a
    Ben> xf:repeat.
    Ben> 
    Ben> A simple solution would be to take attributes much like
    Ben> those used in XSLT [1] -- as alluded to by Leigh -- and
    Ben> allow them anywhere that @nodeset is allowed. For
    Ben> example:
    Ben> 
    Ben> <xf:instance> <countries xmlns="" cur=""> <country
    Ben> id="10" name="USA" /> <country id="20" name="UK" />
    Ben> <country id="30" name="France" /> </countries>
    Ben> </xf:instance>
    Ben> 
    Ben> <xf:select1 ref="@cur"> <xf:label>Choose
    Ben> country:</xf:label> <xf:itemset nodeset="country"
    Ben> sort-key="@name" order="descending"> <xf:label
    Ben> ref="@name" /> <xf:value ref="@id" /> </xf:itemset>
    Ben> </xf:select1>
    Ben> 
    Ben> Output: ___________ Choose country: [___________] V |
    Ben> USA | | UK | | France | |___________|
    Ben> 
    Ben> 
    Ben> By allowing these attributes to operate alongside
    Ben> @nodeset, they would also be available to xf:bind and
    Ben> xf:repeat, too.
    Ben> 
    Ben> However, the obvious next issue would be how to sort by
    Ben> two (or more) columns. For that we'd probably want to
    Ben> make each attribute a list:
    Ben> 
    Ben> <xf:instance> <people xmlns=""> <person id="10"
    Ben> firstname="Leigh" surname="Klotz" /> <person id="20"
    Ben> firstname="Suzan" surname="Foster" /> <person id="10"
    Ben> firstname="T V" surname="Raman" /> </people>
    Ben> </xf:instance>
    Ben> 
    Ben> <xf:repeat nodeset="person" sort-key="@surname,
    Ben> @firstname"> <xf:output value="concat(@surname, ', ',
    Ben> @firstname)" /> </xf:repeat>
    Ben> 
    Ben> Output:
    Ben> 
    Ben> Foster, Suzan Klotz, Leigh Raman, T V
    Ben> 
    Ben> The alternative of using the XSLT approach (specifying
    Ben> the sort order with child elements) could be done, but
    Ben> might get a little tricky to define clearly, given that
    Ben> xf:repeat actually contains the template that is to be
    Ben> repeated:
    Ben> 
    Ben> <xf:repeat nodeset="person"> <xf:sort select="@surname"
    Ben> /> <xf:sort select="@firstname" /> <xf:output
    Ben> value="concat(@surname, ', ', @firstname)" />
    Ben> </xf:repeat>
    Ben> 
    Ben> Anyway, my main point is that there are plenty of things
    Ben> that can be done now, without changing the XForms spec,
    Ben> and still producing interoperable forms. However, there
    Ben> are definitely situations were we need something more
    Ben> than that.
    Ben> 
    Ben> Regards,
    Ben> 
    Ben> Mark
    Ben> 
    Ben> 
    Ben> [1] <http://www.w3.org/TR/xslt.html#sorting>
    Ben> 
    Ben> Mark Birbeck CEO x-port.net Ltd.
    Ben> 
    Ben> e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w:
    Ben> http://www.formsPlayer.com/ b:
    Ben> http://internet-apps.blogspot.com/
    Ben> 
    Ben> Download our XForms processor from
    Ben> http://www.formsPlayer.com/
    Ben> 
    Ben> 
    Klotz,> 
    Klotz,> -- Best Regards, --raman
    Klotz,> ------------------------------------------------------------
    Klotz,> T. V. Raman: PhD (Cornell University) IBM Research:
    Klotz,> Human Language Technologies Architect: RDC ---
    Klotz,> Conversational And Multimodal WWW Standards Phone: 1
    Klotz,> (408) 927 2608 T-Line 457-2608 Fax: 1 (408) 927 3012
    Klotz,> Cell: 1 650 799 5724 Email: tvraman@us.ibm.com WWW:
    Klotz,> http://almaden.ibm.com/u/tvraman
    Klotz,> (google:raman+labrador) AIM: emacspeak GPG:
    Klotz,> http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
    Klotz,> Snail: IBM Almaden Research Center, 650 Harry Road
    Klotz,> San Jose 95120

-- 
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 18:42:16 UTC