W3C home > Mailing lists > Public > www-forms@w3.org > April 2005

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

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Sat, 16 Apr 2005 15:36:17 +0100
Message-ID: <ACFC134D-2301-437A-9A34-25E64E75E710@S009>
To: <tvraman@almaden.ibm.com>, <Leigh.Klotz@pahv.xerox.com>
Cc: <suzan.foster@nerocmediaware.nl>, <www-forms@w3.org>


> An interesting place to start this investigation would be to see if 
> exslt.org has already gone down this (x)path of sorting nodes.

EXSLT.org wouldn't need to, since XSLT itself supports 
sorting. As Leigh says, though, the XSLT way, may be the 
model to look at (see later). First, it might be worth 
separating out where we want to do the sorting -- 
establishing the use cases.

If we want a xf:repeat that behaves like a grid, and (for 
example) clicking on the heading of a column sorts by that 
column, this actually has nothing to do with the XForms 
model, and only relates to the UI. A UI could support this 
feature *now* without requiring any changes to XForms.

Similarly, if you want to sort the nodes in a nodeset -- 
actually re-order them, not just render them differently -- 
then that can be achieved *now* with an extension function 
(most implementations support the definition of extra 
functions that are not part of the base spec).

Whilst these use cases can be done now, there are of course 
others that can't. The main one is where the *author* wants 
the UI to render data in a certain order, independently of 
how the user might interact with that data, and also 
independently of the order of the instance data.

The two situations where this might be the case would be the 
'choices' in an xf:itemset (in xf:select1 and xf:select), and 
of course a list of items in a xf:repeat.

A simple solution would be to take attributes much like those 
used in XSLT [1] -- as alluded to by Leigh -- and allow them 
anywhere that @nodeset is allowed. For example:

    <countries xmlns="" cur="">
      <country id="10" name="USA" />
      <country id="20" name="UK" />
      <country id="30" name="France" />

  <xf:select1 ref="@cur">
    <xf:label>Choose country:</xf:label>
    <xf:itemset nodeset="country" sort-key="@name"
      <xf:label ref="@name" />
      <xf:value ref="@id" />

  Choose country: [___________] V
                  | USA       |
                  | UK        |
                  | France    |

By allowing these attributes to operate alongside @nodeset, 
they would also be available to xf:bind and xf:repeat, too.

However, the obvious next issue would be how to sort by two 
(or more) columns. For that we'd probably want to make each 
attribute a list:

    <people xmlns="">
      <person id="10" firstname="Leigh" surname="Klotz" />
      <person id="20" firstname="Suzan" surname="Foster" />
      <person id="10" firstname="T V" surname="Raman" />

  <xf:repeat nodeset="person" sort-key="@surname, @firstname">
    <xf:output value="concat(@surname, ', ', @firstname)" />


  Foster, Suzan
  Klotz, Leigh
  Raman, T V

The alternative of using the XSLT approach (specifying the 
sort order with child elements) could be done, but might get 
a little tricky to define clearly, given that xf:repeat 
actually contains the template that is to be repeated:

  <xf:repeat nodeset="person">
    <xf:sort select="@surname" />
    <xf:sort select="@firstname" />
    <xf:output value="concat(@surname, ', ', @firstname)" />

Anyway, my main point is that there are plenty of things that 
can be done now, without changing the XForms spec, and still 
producing interoperable forms. However, there are definitely 
situations were we need something more than that.



[1] <http://www.w3.org/TR/xslt.html#sorting>

Mark Birbeck
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
Received on Saturday, 16 April 2005 14:36:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:15 UTC