Details/Filters consistency problems

[istvanrath]

I have seen massive problems, but I cannot reproduce them deterministically:

• the most likely root cause is that the order of parameters in the table seems to be changing randomly. An order change can happen at any time, resulting in inconsistency as follows:
  • input parameterization does not seem to take types properly into account, incorrect typing can be done resulting in user confusion
  • sometimes input parameters are assigned to the wrong header variable, resulting in incorrect results being displayed

Tried with school example:

• load BUTE.school
• focus on coursesOfTeacher

Improvement would also be necessary on the Model element selection dialog, using better strings in the list rather than ugly .toStrings().

[szabta89]

As a side note: if the generated EMF plug-ins are in the runtime config, then the label will not be the toString() rather the text coming from the generated LabelProvider.

[istvanrath]

Nope, I had them in the runtime and it didn't work.

[ujhelyiz]

Hmm, the parameter ordering issue might have something to do with my last change for #329, the comparator. I haven't opened the code yet, but commit 459517ad103e8434f51fb9caf2f9916888ffaac2 might worth a look.

[ujhelyiz]

I updated the comparator to maintain parameter order. @istvanrath can you check whether the symptoms are still there?

[szabta89]

Label provider issue: the generated edit code registers the adapter factory under the http:///school.ecore uri, but the Resource and model elements return the uri as http://school.ecore (one '/' mark is missing). This way the UI cannot find it when it is needed.

[ujhelyiz]

So, the good old EMF generation issues already removed in #174 wanted a rematch. :D

[szabta89]

@ujhelyiz I think the filter setting dialog is more robust now, but the ViewerComparator has no effect in my opinion. For example, for the coursesOfTeacher pattern the order of the pattern parameters is T, C and the comparator calculates this order properly, however, the tableviewer presents them in a reversed order.

I tried to use parameterMap.put(parameterNames[i], Integer.valueOf(parameterNames.length - 1 - i)); in the constructor but the result was the same reversed order.

[szabta89]

@istvanrath Please try to hack the filter setting window!

[istvanrath]

I can't reproduce the issue anymore. Now the order of entries in the Details/Filters view seems to be stable.

[istvanrath]

I have also fixed the school example URI problem.

[istvanrath]

Please cherry pick it to the maintenance branch.

[szabta89]

Cherry picked into maintenance branch.

[istvanrath]

Target ordering for the Details/Filters view:

1. parameters according to the header specification order in the pattern definition
2. then any observable value in alphanumeric order

[istvanrath]

@szabta89 please finish this task by implementing correct ordering

[szabta89]

Sorry for the confusing feedback, but the comparator already did what it was supposed to do. The problem was that I've only tried it with parameters coming from the pattern definition.

[ujhelyiz]

@istvanrath Please check whether everything works as expected.