Last modified: 2013-04-28 12:41:43 UTC
I use SIO to enable users via SF to create a simple table with two rows: a process step and a description. The proces steps are numbered (without a separate number field yet). It seems to work fine, but in the resulting page, the order of the individual entries is wrong. You can see it here: http://cc.pyrotirol.at/wiki/index.php?title=Bauanzeige&action=formedit click on "Prozessablauf/Erläuterungen" You can see the two rows. In the first row, most entries start with a numbering and the order from 1 to 21 is correct. Here you can see that in the source of the page, the order still is correct: http://cc.pyrotirol.at/wiki/index.php?title=Bauanzeige&action=edit But, strangely enough, in the view of the page, the numbering is wrong, the rows get confused: http://cc.pyrotirol.at/wiki/index.php?title=Bauanzeige Here I see 1, 6, 7, ...
Hi - sorry for the delay. I don't see that ordering in the last URL you linked to - is this still a problem?
You were right, wen I cange the property of the field from string to number, the sorting is correct, so this is at least a workaround. But the initial problem was that the entries get sorted at all. I tried to use SIO/SF as sort of an input mechanism for a simple table with the columns "process" and "decription". And I wanted the result just being the same set of rows in the order I entered them. But without any sort= statement in the ask query, the entries got sorted. Strangely enough I cannot reproduce the problem any more!?!
Well, sorting is all done by SMW - not by SF or SIO. I'm guessing that this was some temporary sorting bug in SMW, that has since been fixed. I'm marking this bug as "fixed", in that case.
I see the same here on an internal wiki. I think this is caused by the page names created by SIO. As soon as the number exceeds 10: MyPage#10 MyPage#11 MyPage#5 MyPage#6 MyPage#7 A possible fix would be to use leading zeros: MyPage#006 MyPage#007
I should have marked this as "fixed" a while ago - I added those leading zeroes a few months ago. Though it doesn't matter that much, since now #set_internal usually just calls #subobject anyway.
