Refactoring des FahrtVos für bessere Performance

Im FahrtVo sind die Listen der Leistungen unnötig. LL, LPL und RCP gibt's sowieso nicht mehr, und von den TL brauchen wir nur die erste. Alle Trassenleistungen werden erst beim Aufklappen benötigt.

Refactoring 1

• Service getLeistungen(FahrtVo) zur Verfügung stellen
  
• alle Listen von Leistungen aus FahrtVo entfernen
  
• nur die erste TL als Feld ins FahrtVo aufnehmen
  

Wenn man genauer hinsieht, brauchen wir im FahrtVo nicht mal die ganze TL, sondern nur die folgenden vier Felder: Zusatznummer, Gewicht, Länge, Kalender. Denn nur diese vier Felder werden im Tree dargestellt. Im Editor brauchen wir keines dieser Felder.

Refactoring 2

• erste TL auch aus FahrtVo entfernen
  
• stattdessen die obigen vier Felder der ersten TL ins FahrtVo mappen
  

Statt die vier Felder einzeln ins FahrtVo aufzunehmen, kann man auch eine Klasse TLInfo entwerfen, die diese vier Felder enthält. Im FahrtVo ist dann nur ein Feld tlInfo, das entweder null ist oder auf die Infos der ersten TL zeigt. Als weitere Optimierung könnte man dann das Info-Feld nur dann befüllen, wenn es nötig ist, also bei Suchen, nicht aber in der get()-Methode für Fahrten.

Die TL- und TR-Verläufe brauchen wir nur im Betriebspunktreiter. Diese beiden Listen könnte man auch noch rausnehmen, und stattdessen nachladen, wenn der User zum ersten Mal auf den Betriebspunktreiter klickt.

Refactoring 3

• TL- und TR-Verlaufslisten aus FahrtVo entfernen
  
• Service getVerläufe(FahrtVo) anbieten, der diese beiden Listen liefert
  

reloadNeeded Flag im SimpleTreeView

Der SimpleTreeView besitzt nun ein reloadNeeded Flag, welches in setQuery gesetzt wird, bevor der ReloadService aufgeweckt wird. Der ReloadService fragt dann später zurück, indem er die Methode needsReload() aufruft und der SimpleTreeView antwortet mit true.

Dadurch wird durch das Setzen eines neuen Queries nun immer ein Reload durchgeführt, wogegen beim Drücken des Reload Buttons nur dann ein Reload stattfindet, wenn der TreeView aktiv ist.

Callable<T>

Will man eine Berechnung mit Display.syncExec(runnable) im Display-Thread laufen lassen und danach das Resultat abholen, steht man vor dem Problem, dass ein Runnable keinen Rückgabewert hat. Eine mögliche (aber schlechte) Lösung wäre, das Resultat des Runnables in einer Klassenvariablen zu speichern und danach auf diese zuzugreifen.

Um diese Einschränkung zu umgehen, gibt es nun die Klasse Callable. Mit dieser kann das Problem nun wie im folgenden Beispiel gelöst werden.

    Callable<Date> callable = new Callable<Date>() {
        public Date call() {
            return sucheBisText.getDate();
        }
    };
    getDisplay().syncExec(callable);
    Date date = callable.getResult();

Neues VM Argument symbolicname

Mit -Dch.sbb.polar.server.symbolicname=Name im Init File kann man nun den symbolischen Namen des Servers, also z.B. Dev oder Test, angeben.