Eigene Smart Elements

Der interne Zustand eines Elementes darf nur über wohl definierte Wege geschehen. Dies muss scharf kontrolliert werden, da nur so für den verteilten Arbeitsbetrieb eine Synchronisation mit mehreren Rechnern erreicht werden kann. Interne Daten dürfen zunächst nur durch die Methoden setProperty, getProperty und tell verändert werden. setProperty() und tell() werden ihrerseits von anderen Objekten NIEMALS direkt aufgerufen. Stattdessen werden die analogen Methoden setPropertyRemote() und tellRemote() aufgerufen. Diese delegieren ihre Arbeit dann an setProperty und tell, sie informieren aber auch andere Teilnehmer.
Es lassen sich jedoch nicht alle internen Änderungen auf einfache Weise mit setPropery und tell abbilden. Daher ist es zulässig, Hilfsmethoden mit beliebiger Signatur einzuführen. Allerdings besteht jede Hilfsmethode aus drei Implementierungen, da auch hier wieder ein direkter Zugriff von aussen unzulässig ist. Statt einer Hilfsmethode setzeIrgendwas(..) sind folgende Methoden zu implementieren:

          switchSetzeIrgendwas(...)
          remoteSetzeIrgendwas(...)
          directSetzeIrgendwas(...)

Die switch-Version der Methode entscheidet dabei, ob der Methodenaufruf direkt innerhalb des Elements geschieht (dies ist der Fall im Stand-Alone-Betrieb) oder über den Server geschieht. Im ersten Fall würde also directSetzeIrgendwas(...) aufgerufen. Im zweiten Fall würde der Methodenaufruf über das Netzwerk erfolgen und an alle Teilnehmer gesendet. Dies wird mit Ausführug eines TCL-Commandos "distributedInvoke" erreicht. Zur Datenkommunikation werden dabei alle Parameter in Strings umgewandelt. Die Serverkomponente von Javanti ruft nun bei allen Teilnehmern die Methode remoteSetzeIrgendwas(...) auf. remoteSetzeIrgenwas(..) empfängt die Parameter wiederum als Strings und muss diese in die erforderlichen Typen umwandeln, um schliesslich ebenfalls directSetzeIrgendwas(...) aufzurufen.

Für die switch-Implementierug ergibt sich somit folgender fester Aufbau:

switchSetzeIrgendwas (Typ1 param1, Typ2 param2 ...) {
    if (TAPRemoteManager.clientIsOnline()) {
        TAPApplication.getInterpreter().evalScriptRemote("distributeInvoke
          "+this.getLayerName()+
          " "+ name+"."+subName + " {remoteSetzeIrgendwas "+
          String.valueOf(param1) + " " +
          String.valueOf(param2) + "}",
          this.getLayerType()
        );
    } else {
        directSetzeIrgendwas(param1, param2);
    }
}

Die Signatur der direct-Implementierung entspricht der switch-Implementierung. Die eigentlichen Aktionen geschehen innerhalb der direct-Implementierung:

switchSetzeIrgendwas (Typ1 param1, Typ2 param2) {
    // beliebige Aktionen
}

Die remote-Implementierung wandelt die Strings wieder in die erforderlichen Typ um und ruft directSetzeIrgendwas auf:

remoteSetzeIrgendwas(String param1, String param2) {
    directIrgendwas ( casteStringNachTyp1 (param1) ,
                      casteStringNachTyp2 (param2) );
}

Diese Merkmale müssen nun vom eingehalten werden:

• die feste Struktur von switchSetzeIrgendwas sollte eingehalt werden
• switchSetzeIrgendwas darf keine Datenfelder verändern
• remoteSetzeIrgendwas darf keine Datenfelder verändern
• Alle Objekte, die vom Plug-In-Entwickler irgendwann erzeugt werden (könnten), dürfen AUSSCHLISSLICH die Methoden setPropertyRemote, tellRemote, getProperty und alle mit switch beginnenden Methoden (wenn diese den oben beschriebenen Anforderungen entsprechen) aufrufen. Dies ist insbesondere für alle Referenzen auf andere Elemente und die Swing-Komponenten sowie deren registrierte Listener zu überprüfen. Die anderen Methoden dürfen NUR durch das jeweilige Element-Objekt selbst aufgerufen werden