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.

Neuer Callback postOpen(input) im PolarEditor

Der PolarEditorPart hat eine neue Callback-Methode postOpen(PolarEditorInput input), die vom EditorExpert nach dem Öffnen (oder Reaktivieren) des Editors aufgerufen wird.

Der PolarEditorInput erfüllt nun insgesamt drei Zwecke:

1. Er enthält Informationen, die zur Identifikation des Editors verwendet werden: in POLAR ist dies zur Zeit der String für den Editor-Titel. Anhand dieses Attributs entscheidet Eclipse, ob ein neuer Editor geöffnet oder ein alter reaktiviert wird.
   
2. Er enthält Informationen, die zur Erzeugung eines neuen Editors verwendet werden, nämlich das PolarVo und das Startdatum der Instanz (welches bei Planungsobjekten null ist).
   
3. Er enthält Informationen, die in postOpen() verwendet werden, um den Editor nach dem Öffnen bzw. Reaktivieren zu konfigurieren. Aktuell verwendet wird hier das Feld tabItemIndex, das angibt, welches TabItem zu Beginn selektiert sein soll (Default: 0).
   

Damit ist es nun möglich, ein Feature wie "öffne das gegebene VO und selektiere den VT-Reiter" folgendermassen zu implementieren:

             
    PolarEditorInput input = new PolarEditorInput(vo);
    input.setTabItemIndex(2);
    EditorExpert.openEditor(input, true);

Die postOpen()-Methode des TabFolderEditors sieht dabei aktuell so aus:

    public void postOpen(PolarEditorInput input) {
        tabFolder.setSelection(input.getTabItemIndex());
    }

Neues Feature: Arbeitsliste

Die Arbeitsliste ist ein leerer TableTree, in den Objekte mit Drag & Drop hineingezogen werden können. So kann der User beliebige Objekte aus verschiedenen Trees aufsammeln und in die Arbeitsliste ziehen, um sie dort weiterzubearbeiten, oder um z.B. anschliessend die Arbeitsliste nach Excel zu exportieren.

Neues Projekt LaunchConfigurations

Die verschiedenen Konfigurationen, um POLAR aus der Eclipse IDE heraus zu starten, sind ab jetzt nicht mehr im BasePlugin, sondern in einem eigenen Projekt LaunchConfigurations. Bis jetzt gibt es dort 2 Konfigurationen für PolarDev, eine für Eclipse 3.2 und eine für 3.3.