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

this is a good summary, Thanks.

I think we should think carefully about re-ordering on the UI
side without sorting things in the data layer; 
there are pros and cons to doing that.

It would be simplest to keep the UI reflecting the stte of the
data model, which is why I suggested sorting the data.

The XSLT route would also be easy to try in current browsers most
of which support XSLT through the XSLTProc scripting function;
incidentally this is what GoogleMaps uses in both IE and Mozilla,
which is also one of the reasons GoogleMaps fails in back-level
browsers like Opera that do not understand XPath, leave alone
XSLT.

So as a first step in figuring out the use cases that we need to
support, I'd suggest experimenting in IE Formsplayer and FireFox
XForms by implementing the sort via XSLT called through XSLTProc
to rearrange the nodes in the instance.

Here are some of the sort use cases I've seen on the Web  today:

a) Phone bills; allow you to sort the list of calls according to
various criteria

B) Shopping sites of course.

In general sort today shows up in grid layouts achieved via
scripting, but a more interesting use case that doesn't show up
on today's Web mostly due to the limitations of what has been
possible is dynamic sorting of deeply nested structured data
whereby things of interest bubble to to the top of the tree as
the user specifies some input.

As an example, consider a collection of all  airports in the
world organized as a structured tree. Navigating this tree
typically would take a   sequence of interaction gestures to open
up multiple levels of the tree.
You can implement nested tree navigation as has already been
shown by Mark Birbeck in FormsPlayer; it would be interesting to
first lash together the ability to sort the data nodes using XSLT
--- and having that functionality in place, 
start doing some experimentation on the above tree navigation
example to see if we could speed up task completion by sorting as
the user types i.e. the equivalent of Emacs incremental search
with the effect showing up on the display by the tree reforming
itself to reflect the items to be most likely of interest.

The best thing about all this is that with what we have in place,
a chunk of experimentation can be done before any spec writing.

>>>>> "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
    Ben> select="@surname" /> <xf:sort select="@firstname" />
    Ben> <xf:output 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> 

-- 
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 Saturday, 16 April 2005 16:34:19 UTC