Incorrect XSLT Sorting Options
GroennDemon
Posted: Sunday, February 10, 2008 11:39:19 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
I have nodes (with a date as the title) which are (manually) sorted correctly in the backend:



However, using this XSLT:

Code:
<xsl:for-each select="child::node">
<xsl:sort select="position()" order="descending" />


I get the wrong order in the rendered page (it is only correct for some of the nodes, which I have marked in the image):



How can this be fixed?
drobar
Posted: Monday, February 11, 2008 12:58:24 AM

Rank: Umbracoholic

Joined: 9/8/2006
Posts: 1,410
Location: KY, USA
I'm not entirely sure why your xslt isn't producing the output it should, but I will note that you don't need to do any <xsl:sort.../> if you want to use the nodes in the order in which they appear in the content tree.

However, since you want to return the nodes in reverse order, and you have well-formed and consistently named nodes... maybe you could specify a more precise sort algorithm that doesn't rely on the order in the content tree, thereby making your macro more resilient mistakes by content editors in the future.

You might look at http://forum.umbraco.org/20383#post-20396 for an idea about using the umbraco.library:FormatDate() function. I'm not sure if it will work if you try to pass in the @nodeName instead of a true date field. It might not work. I've never tried it.


Or, consider changing your node naming scheme to be naturally sortable by specifying the year, then the month, and then the day. Then you can simply use <xsl:sort select="@nodeName" order="descending"/>

If you don't want to rename your nodes, another option would be to use one of the Exslt functions to split up your @nodeName into its constituent parts (day, month, year) and sort accordingly:

<xsl:value-of select="Exslt.ExsltRegularExpressions:tokenize('String str', 'String regexp')"/>


cheers,
doug.


MVP 2007-2009 - Official Umbraco Trainer for North America - Percipient Studios
PeterD
Posted: Monday, February 11, 2008 10:41:50 AM

Rank: Fanatic

Joined: 7/20/2006
Posts: 453
Location: NL
Douglas Robar wrote:

I'm not entirely sure why your xslt isn't producing the output it should, but I will note that you don't need to do any <xsl:sort.../> if you want to use the nodes in the order in which they appear in the content tree.


Hm, I have to disagree on this part Douglas. I have had a few occasions when the nodes showed correctly in my tree but where shown in a different order on the front-end.
I solved this by using a
xsl:sort select="@sortOrder" order="ascending"

Perhaphs this might help Marvin also.

HTH,
PeterD


Working on an events-calendar with recursion. Post requests on my blog!
mortenbock
Posted: Monday, February 11, 2008 11:15:41 AM

Rank: Addict

Joined: 7/19/2006
Posts: 738
Location: Århus, Denmark
It is probably caused by the bug that causes umbraco not to update it's cache correctly when sorting occurs. This has been registered at codeplex and should be fixed, but it's good to set Peters solution...

Morten Bock - Level 2 certified - MVP 2008/2009 - My danish blog with a few english posts

PeterD
Posted: Monday, February 11, 2008 3:56:23 PM

Rank: Fanatic

Joined: 7/20/2006
Posts: 453
Location: NL
I just encoutered this problem again and adding the sort by sortorder did the trick again
:D

Working on an events-calendar with recursion. Post requests on my blog!
bootnumlock
Posted: Monday, February 11, 2008 5:45:59 PM

Rank: Fanatic

Joined: 10/9/2006
Posts: 352
I have actually found that if you use a macro once [meaning in one template] it will sort fine without specifying the @sortOrder...

however, if you use that same macro/xslt on a second template... it sorts in some way that i cannot even determine... and the @sortOrder is then needed for the xlst to function as desired.

just my .02

bootnumlock - aka bob baty-barr [http://www.baty-barr.com]
Level 1 Certified!
drobar
Posted: Monday, February 11, 2008 5:50:39 PM

Rank: Umbracoholic

Joined: 9/8/2006
Posts: 1,410
Location: KY, USA
Hi, Peter,

I like your solution as a sure way to get around a bug in umbraco. It is simple and obvious.

But it is a bug in umbraco that sorting doesn't always update the internals to reflect what appears in the content tree view.

The few times I've run into the sorting bug I have simply right-clicked on the node above those that are mis-sorted and selected the "publish" menu item, being sure to place a checkmark in the "publish children" field. Note that this is NOT the same as the "republish entire site" menu item on the top-most CONTENT node; they do very different things.

Can you try publishing with children to see if that resolves the sorting problem you're experiencing? If so, then there are two sure ways to resolve the problem... republish the nodes, and/or add the <xsl:sort.../>.

cheers,
doug.

MVP 2007-2009 - Official Umbraco Trainer for North America - Percipient Studios
PeterD
Posted: Monday, February 11, 2008 6:17:06 PM

Rank: Fanatic

Joined: 7/20/2006
Posts: 453
Location: NL
Same thing came to mind today when I had the issue again.
So, I tried exactly as you described but it gave no result. I ended up adding my extra line in the XSLT again.....

PeterD

Working on an events-calendar with recursion. Post requests on my blog!
GroennDemon
Posted: Tuesday, February 12, 2008 9:20:34 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
Neither republishing the nodes (both the content nodes nor the node containing the macro) nor sorting by @sortOrder helped. :(

Btw, it's Umbraco 2.1.6.
mortenbock
Posted: Tuesday, February 12, 2008 9:31:32 PM

Rank: Addict

Joined: 7/19/2006
Posts: 738
Location: Århus, Denmark
Marvin Massih wrote:

Neither republishing the nodes (both the content nodes nor the node containing the macro) nor sorting by @sortOrder helped. :(

Btw, it's Umbraco 2.1.6.


I experienced something like this on a 2.1.6 today. There really is something fishy about the sorting. My next step is upgrading to 3.0.3 hoping that this will at least help to be able to use the @sortOrder fix suggested here.

Morten Bock - Level 2 certified - MVP 2008/2009 - My danish blog with a few english posts

GroennDemon
Posted: Tuesday, February 12, 2008 9:37:12 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
Hi Morten,

please let me know if that worked out.
I had tried v3 a while ago and it seemed a lot more unstable than 2.1.6 at that time.
GroennDemon
Posted: Thursday, March 20, 2008 10:09:32 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
I have upgraded to v3... republishing the nodes, sorting by @sortOrder... none of it helps, the sorting is completely broken.
Guess I won't have to tell you that the client is very unhappy.

Any other suggestions?
mortenbock
Posted: Friday, March 21, 2008 9:37:09 AM

Rank: Addict

Joined: 7/19/2006
Posts: 738
Location: Århus, Denmark
In my case, upgrading to V3 helped in the way that I can now:

1: Sort the nodes in the administration
2: Right click the Content node and "Republish entire site"

But if this is not working for you, maybe there is something else you need to look at. I don't know if it could be a problem with you setup somehow? What happens if you "touch" the web.config file? That should force the cache to update from the database. Does this update your macro to the right sort order?

For a workaround, maybe you could try to sort by pagename, and do some string manipulation to make that work?

Morten Bock - Level 2 certified - MVP 2008/2009 - My danish blog with a few english posts

GroennDemon
Posted: Friday, March 21, 2008 12:01:34 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
I have found the problem:

The nodes are sorted as strings! The nodes with @sortOrder=11, 12, 13 etc. come before those with 2, 3, 4.

How can I make Umbraco compare the values as integers?
GroennDemon
Posted: Friday, March 21, 2008 12:06:43 PM
Rank: Aficionado

Joined: 7/30/2006
Posts: 104
Finally! This worked:

Code:
<xsl:sort select="@sortOrder" data-type="number" order="ascending" />
mortenbock
Posted: Friday, March 21, 2008 12:39:39 PM

Rank: Addict

Joined: 7/19/2006
Posts: 738
Location: Århus, Denmark
GroennDemon wrote:

The nodes are sorted as strings! The nodes with @sortOrder=11, 12, 13 etc. come before those with 2, 3, 4.


Well that explains a lot! I wonder if this should be added to codeplex as a bug? Does it sort as a string even if you have no xsl:sort in your macro?

Morten Bock - Level 2 certified - MVP 2008/2009 - My danish blog with a few english posts

jesperw
Posted: Friday, March 21, 2008 2:45:29 PM
Rank: Enthusiast

Joined: 9/6/2007
Posts: 10
This is not a bug, its by design.

Sorting as a number is different from sorting as a string. Strings are sorted by comparing individual character values from left to right (and this ordering is different between locales).

Why 12 would come after 112:
Example:
We have a list of values

12
112

We want to order these values by string comparison ascending.

1. First character is compared [1]2 vs [1]12. Both have a 1 as first character making them equal, no reordering is needed.
2. Second character is compared 1[2] vs 1[1]2: 2 is greater than 1 making the string 12 being positioned after string 112. (they swap places in the list)
3. No reason to compare the last character of the strings since because the strings cannot change position again.

the output would be:

112
12

On the subject of position():
As from my experience the xslt expression position() is representing the actual position of the cursor when iterating through a node-set (useful for getting the actual position in a for-each). I believe using descending on this would make the nodes default sort order invert (last node comes first and so on). From my experience the default sort order of the node tree is by nodeId. Since the nodeId is increased for each node being created, the default order is by oldest created node first (lower nodeId) and most recently created last (higher nodeId).

This has nothing to do with the sortOrder of the umbraco nodes since sortOrder is just an attribute of the node. Changing the sortOrder attribute of the nodes does not make the nodes change position in the node tree.

/Jesper Wigelius
Users browsing this topic
Guest


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.