Fix doc tests and inconsistencies with sorting criteria in lists

[xispa]

Description of the issue/feature this PR addresses

This PR fixes the failures in doc tests UIDReferenceTest.rst and ShowPrices.rst. The former was failing because of the assumption the function getDependentServices returned the services sorted by title. The function returns de dependent services correctly, but don't care about the order. The latter was failing because of inconsistencies in the assignment of sorting criteria when rendering lists.

To resolve these inconsistencies, the logic regarding sort_on and sort_order in lists has been refactored.

Basically, sort_on var was meant to refer to table column, but is oftenly used to set the index for which the list must be sorted against. This inconsistence is the reason of the warnings and the perplexity of devs that never know what sort_on acts like (sometimes, sort_on is obtained from the request as a colunm name, but in other cases, expects an index, etc.). This refactoring takes all this into account and always tries to return the index (better because the sorting is done directly when querying) and if not, returns the name of the column, but tells the system the sorting must be done programatically. sort_on value set in the request gets priority over the sort_on value set in contentFilter and in turn, sort_on value set in contentFilter gets priority over the value set in self.sort_on. If no matches found against columns or indexes for any of these values, the system uses created index as a sort_on fallback.

Current behavior before PR

Doctests UIDReferenceTest.rst and ShowPrices.rst fail.

Desired behavior after PR is merged

Doctests UIDReferenceTest.rst and ShowPrices.rst pass

--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.

[ramonski]

Except for one possible KeyError, I do not see any code problems with this PR. Please decide if you would like to change, otherwise I'm ok to merge that one.

[ramonski]

Why did you do that function within the method? In my opinion this increases complexity without any additional advantage

[xispa]

I had to check the same (if the value is set in columns and/or in indexes) for each sort_on possible sources (self.request, self.contentFilter and self.sort_on), so instead of triplicating the same code or placing it into the loop (see L808), I though this way would be better.

[ramonski]

Not sure when this happens, but this fails for an empty list/tuple with a KeyError

[xispa]

Well spotted, I missed to evaluate the type against the list.

[ramonski]

better use isinstance(sort_value, (list, tuple)) and then len(sort_value)==1