Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Robotlegs - Ein Blick unter die Haube - Teil 1

Im letz­ten Techblog Artikel über MVC Frameworks bin ich schon ein wenig auf das Robotlegs (RL) Framework ein­ge­gan­gen. Dieser Artikel behan­delt die Thematik aus­führ­li­cher und zeigt, wel­che Besonderheiten es bei RL zu beach­ten gibt und wie das Framework ver­wen­det wer­den kann.

Typisch für RL ist die Aufsplittung des Codes in meh­rere  Schichten. Dabei setzt sich das Gesamtpaket aus fol­gen­den Teilen zusam­men:

  • Kontext
  • View & Mediatoren
  • Commands (Controller)
  • Services (optio­nal)

Der Kontext bil­det das Herzstück der Applikation und stellt auch den zen­tra­len “Event-Bus” dar. In ihm wer­den alle "Drähte" gezo­gen und Bekanntmachungen getrof­fen. Flash bie­tet ein eige­nes Eventsystem, wel­ches RL nut­zen kann um die ein­zel­nen Bestandteile der Applikation zu steu­ern. Ohne die Events wäre es nicht mög­lich, dass Services oder Models Informationen an Controller sen­den könn­ten. Wer sich jedoch ,wie ich ,von dem Eventsystem los kop­peln möchte, dem bie­tet RL die Möglichkeit die AS3 Signals Bibliotheken von Robert Penner zu ver­wen­den. Dadurch kann nahezu kom­plett auf die Verwendung der Flash Events ver­zich­tet wer­den. Die "Signals" fun­gie­ren dann als Trigger für die Commands bzw. Controller.

Die Standard RL Implementierung bie­tet keine Möglichkeit Signals direkt zu ver­wen­den. Um diese zu ver­wen­den wer­den die fol­gen­den bei­den Bibliotheken benö­tigt:

import org.robotlegs.mvcs.SignalContext;

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

Die SignalCommandMap ermög­licht es anstelle der Basisklasse Context, den SignalContext zu ver­wen­den. Dieser bringt die SignalCommandMap mit sich, in die­ser dann alle Signals auf Commands gemappt wer­den kön­nen. Alle ande­ren Robotlegs Maps blei­ben unver­än­dert (mapSingletonOf, mapSingleton).

signalCommandMap.mapSignalClass(StartSignal,StartCommand);

Eine Erfahrung, die ich in der Projektarbeit mit RL gesam­melt habe ist, dass der Kontext nicht sehr häu­fig ver­wen­det wird. Er ist das erste mit dem sich der Entwickler beschäf­ti­gen muss, da dort alle initia­len Konfigurationen getrof­fen wer­den, aber er muss wäh­rend der Entwicklungszeit so gut wie nicht mehr ver­än­dert wer­den.

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

Beispielweise wer­den in ihm Models und Service für die spä­tere Injektzierung mit­tels [inject] vor­be­rei­tet.

Nachdem der Kontext fer­tig erstellt wurde muss die­ser der Applikation noch bekannt gemacht wer­den. 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 inner­halb des Deklarations Tags refe­ren­ziert wer­den. Innerhalb der Referenz muss die Root View ange­ge­ben wer­den. Im Beispiel ist diese auf "contextView="{this}"" gesetzt. Um spä­ter einen Mediator auf diese RootView zu map­pen genügt die fol­gende Festlegung. Mehr dazu jedoch im Teil 2 der Artikelreihe.

mediatorMap.mapView(MyContextApp, ApplicationMediator);

Eine Applikation muss nicht zwin­gend genau eine Kontext Klasse besit­zen. Es ist durch­aus mög­lich meh­rere Kontexte zu defi­nie­ren. Das ist vor allem dann sinn­voll wenn die Anwendung modu­lar auf­ge­baut wer­den soll.

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

Related Posts

Pin It on Pinterest