Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

Robotlegs – Ein Blick unter die Haube – Teil 1

Im letzten Techblog Artikel über MVC Frameworks bin ich schon ein wenig auf das Robotlegs (RL) Framework eingegangen. Dieser Artikel behandelt die Thematik ausführlicher und zeigt, welche Besonderheiten es bei RL zu beachten gibt und wie das Framework verwendet werden kann.

Typisch für RL ist die Aufsplittung des Codes in mehrere  Schichten. Dabei setzt sich das Gesamtpaket aus folgenden Teilen zusammen:

  • Kontext
  • View & Mediatoren
  • Commands (Controller)
  • Services (optional)

Der Kontext bildet das Herzstück der Applikation und stellt auch den zentralen “Event-Bus” dar. In ihm werden alle „Drähte“ gezogen und Bekanntmachungen getroffen. Flash bietet ein eigenes Eventsystem, welches RL nutzen kann um die einzelnen Bestandteile der Applikation zu steuern. Ohne die Events wäre es nicht möglich, dass Services oder Models Informationen an Controller senden könnten. Wer sich jedoch ,wie ich ,von dem Eventsystem los koppeln möchte, dem bietet RL die Möglichkeit die AS3 Signals Bibliotheken von Robert Penner zu verwenden. Dadurch kann nahezu komplett auf die Verwendung der Flash Events verzichtet werden. Die „Signals“ fungieren dann als Trigger für die Commands bzw. Controller.

Die Standard RL Implementierung bietet keine Möglichkeit Signals direkt zu verwenden. Um diese zu verwenden werden die folgenden beiden Bibliotheken benötigt:

import org.robotlegs.mvcs.SignalContext;

public class MyContext extends SignalContext
{
 public override function startup():void
 {
 }
}

Die SignalCommandMap ermöglicht es anstelle der Basisklasse Context, den SignalContext zu verwenden. Dieser bringt die SignalCommandMap mit sich, in dieser dann alle Signals auf Commands gemappt werden können. Alle anderen Robotlegs Maps bleiben unverändert (mapSingletonOf, mapSingleton).

signalCommandMap.mapSignalClass(StartSignal,StartCommand);

Eine Erfahrung, die ich in der Projektarbeit mit RL gesammelt habe ist, dass der Kontext nicht sehr häufig verwendet wird. Er ist das erste mit dem sich der Entwickler beschäftigen muss, da dort alle initialen Konfigurationen getroffen werden, aber er muss während der Entwicklungszeit so gut wie nicht mehr verändert werden.

injector.mapSingleton(StateModel);
injector.mapSingletonOf(IService,Service);

Beispielweise werden in ihm Models und Service für die spätere Injektzierung mittels [inject] vorbereitet.

Nachdem der Kontext fertig erstellt wurde muss dieser der Applikation noch bekannt gemacht werden. Dies geschieht in einer Flex 3 bzw. 4 Anwendung über die Haupt MXML Datei.

<fx:Declarations>
<MyContextApp:MyContext contextView="{this}" />
</fx:Declarations>

Der Kontext muss innerhalb des Deklarations Tags referenziert werden. Innerhalb der Referenz muss die Root View angegeben werden. Im Beispiel ist diese auf „contextView=“{this}““ gesetzt. Um später einen Mediator auf diese RootView zu mappen genügt die folgende Festlegung. Mehr dazu jedoch im Teil 2 der Artikelreihe.

mediatorMap.mapView(MyContextApp, ApplicationMediator);

Eine Applikation muss nicht zwingend genau eine Kontext Klasse besitzen. Es ist durchaus möglich mehrere Kontexte zu definieren. Das ist vor allem dann sinnvoll wenn die Anwendung modular aufgebaut werden soll.

Was es mit den Views & Mediatoren auf sich hat erfahrt ihr im nächsten Artikel.

Kommentar hinterlassen


Pin It on Pinterest