Completed

A domain setting to be able to sort by element translation or by database value

  • 6 May 2019
  • 6 replies
  • 169 views

Userlevel 3
Badge +6
The elements of a domain are always sorted in alphabetical order of the translation. If you want to sort based on the database value, you need to create an expression column (hidden and sorted). This will only work for the 'default sorting'. If you sort on the displayed column, it will still sort alphabetical.

Another disadvantage of the work around is, that you need to specify an expression column for each table. Take for example a domain 'calendar_month' with elements: January (db-value=1), February (db-value=2) etc.

It would be better to specify this once (domain).

6 replies

Userlevel 5
Badge +8
Andre,

I think (!!) it's the other way around... I had a wish last year in TCP that will be closed today, because wishes entere here and no longer in TCP. In my case I wanted to be able to have the GUI sort elements alphabetically (so on the translation), because when using various languages in the GUI things sometimes look a bit odd translated in the pulldown. It could be that in a previous version of the SF things worked the other way around, Or perhaps things work differently in the Windows or Web GUI ( wouldn't be the first time).

I do, however, wish it was possible to determine on domain level whether to sort on translation or on sequence number of the elements.

Elements are not sorted on database value but on "Sequence no" entered in the domain element. I'm using SF 2018.3 and just tested this by changing the translation of Kilometers to Zilometers


After changing the translation and refreshing the model:



But when I change the Sequence number of the domain element in de project from 10 to 100


The value Kilometers is at the bottom of the list.

Userlevel 3
Badge +4
As a developer I would like to be able to sort on each of database value, translation object, translated object and on predefined (numeric) sorting order, and be able to make that choice in the GUI.

From a usability/intuitive standpoint, I would argue an alfanumerical sorting should always be on the data that is visible to the user, ie, using the translated values.
Userlevel 3
Badge +6
You are right. The elements in a combo are ordered based on the order number of the element.

In this case it's about sorting in a list (grid) or cube. That might not be clear, because it was first entered as a question.

When I sort a list based on a column with domain elements it will sort the list in alphabetical order of the element translation. Take for example a domain 'month' (1 = January, ….). When I want to sort this, I have to use another column with the number of the month.
Userlevel 3
Badge +6
As a developer I would like to be able to sort on each of database value, translation object, translated object and on predefined (numeric) sorting order, and be able to make that choice in the GUI.

It would be nice if you could overrule the default behavior (domain), but I'm happy if I could choose🙂
Userlevel 3
Badge +1
If anything, from a usability standpoint the order of items in the dropdown should match how items are ordered in the grid. This is clearly not the case, which in my opinion is a bug.

However, without some kind of model setting I'm reluctant to fix this because we'd have to decide what ordering is 'correct'. Lexical ordering is the obvious choice, but as stated above this breaks expected behavior in some dropdowns in existing models.

I've created issue 71878 for this in TCP.
Userlevel 3
Badge +1

This feature will become available in the next version of the Software Factory, 2020.1. For each domain with elements, one can choose between lexical ordering (by translation) and order by order number. Dropdowns and sorting in the grid both honor this new setting. This means it will be a breaking change for domains where both orders are different.

Best performance will be to match the order of database values with the order as defined by the order number, and then choosing to order by order number. Clients then omit the case statement from generated select SQL queries.

Reply