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

I can think of lots of reasons to sort ONLY on the UI side.
you may have an application that requires displaying multiple different sort orders of the same or similar information 
simultaneously. the XSLT sort works very well.

my 2 cents.
Jason.


Date sent:      	Sat, 16 Apr 2005 09:34:29 -0700
To:             	Ben.Atfield@x-port.net
Copies to:      	tvraman@almaden.ibm.com, Leigh.Klotz@pahv.xerox.com,
	suzan.foster@nerocmediaware.nl, www-forms@w3.org
Send reply to:  	tvraman@almaden.ibm.com
From:           	"T. V. Raman" <tvraman@us.ibm.com>
Subject:        	RE: How to change the order of repeat-items?
Forwarded by:   	www-forms@w3.org
Date forwarded: 	Sat, 16 Apr 2005 16:34:20 +0000

> 
> 
> 
> 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 Sunday, 17 April 2005 06:40:22 UTC