It won't currently allow that, as it uses the doc type as the trigger for the sort. I'll have a think and see if there is another way to do, without slowing things down.
Matt
Great, thanks for your quick addition! I used rootXpath to set the root to a particular nodeId, but then I did not get sorting on the grandchildren of that node, only the children was sorted. So I guess I need to set rootXpath to some "all nodes under @id"-xslt-expression, to sort the grandchildren aswell, right?
Another thing ... The editors are asking for a way for them to control the sorting... And I also think it's a good idea to let the site owners take control of it. Perhaps by using a property with a standardized name, perhaps just SortThisNode=true/false (using the settings from the config file)... Or, even better, add one property for what to sort on (ex "nodeName"), and one how to sort (ex "AlphaAscending").
Some more good ideas. It should be easy enough to make the sorting configurable at run time as you say with some predfined property alias' (docSorterField, docSorterType and docSorterOrder). I would imagin you would want the parent node to define how you want it's child nodes sorted? (This is how EPIServer works). Maybe making this cascade down should you have grand children. Just wondering what would be the best way to tell the docSorter which node to retrieve the config from? Another XPath statement? configXpath?
RE your rootXpath, it does sound like you do just need a more refined expression. FYI grandchildren won't sort when a CHILD node is saved / published, but it should be possible to have a rootXpath statement that would make granchildren sort when a grandchild is saved / published (I think that makes sence).
Let me know what you think re my thoughts on the config.
Hmmm, weird, resaved the project and seems to download fine now.
Yea, if we had the docSorter properties you would probably still need the config to say which nodes to trigger the sort on and I think it would still be good to have the option to just to it automatic.
Next time I get a bit of spare time, I'll have a look at implementing and let you know.
Sorting all nodes, no matter which document type
Hi!
Very useful package, thanks for sharing!
I have some nodes containing children with different document types, is it possible to have them sorted (by nodeName)?
Regards
Jonas
It won't currently allow that, as it uses the doc type as the trigger for the sort. I'll have a think and see if there is another way to do, without slowing things down. Matt
Hi Jonas,
I've published an update which makes docTypeAlias optional. If undefined, the sort applies to all nodes.
If you don't define docTypeAlias, it is advised that you set rootXpath to narrow down the scope of the sort, and to limit unexpected sorting.
Many thanks
Matt
Great, thanks for your quick addition! I used rootXpath to set the root to a particular nodeId, but then I did not get sorting on the grandchildren of that node, only the children was sorted. So I guess I need to set rootXpath to some "all nodes under @id"-xslt-expression, to sort the grandchildren aswell, right?
Another thing ... The editors are asking for a way for them to control the sorting... And I also think it's a good idea to let the site owners take control of it. Perhaps by using a property with a standardized name, perhaps just SortThisNode=true/false (using the settings from the config file)... Or, even better, add one property for what to sort on (ex "nodeName"), and one how to sort (ex "AlphaAscending").
Regards
Jonas
Hey Jonas,
Some more good ideas. It should be easy enough to make the sorting configurable at run time as you say with some predfined property alias' (docSorterField, docSorterType and docSorterOrder). I would imagin you would want the parent node to define how you want it's child nodes sorted? (This is how EPIServer works). Maybe making this cascade down should you have grand children. Just wondering what would be the best way to tell the docSorter which node to retrieve the config from? Another XPath statement? configXpath?
RE your rootXpath, it does sound like you do just need a more refined expression. FYI grandchildren won't sort when a CHILD node is saved / published, but it should be possible to have a rootXpath statement that would make granchildren sort when a grandchild is saved / published (I think that makes sence).
Let me know what you think re my thoughts on the config.
Cheers
Matt
Hi Matt,
I tested version 1.0.2 now and it also took care of a bug I had noticed but forgot to mention (publishing nodes on level 1), nice!
(For some reason I could not download from the big blue Download link (in the green box). YSOD "Could not find file...")
Yeah, docSorter-properties (cascading) would be a great feature! But with that props you would not need config at all, would you?
RootXpath, ok, will try that, and saving grandchildren to sort'em makes sence.
Cheers
Jonas
Hmmm, weird, resaved the project and seems to download fine now.
Yea, if we had the docSorter properties you would probably still need the config to say which nodes to trigger the sort on and I think it would still be good to have the option to just to it automatic.
Next time I get a bit of spare time, I'll have a look at implementing and let you know.
Matt
Cool, looking forward to it, let me know if I can be of any help testing or whatever.
is working on a reply...