Zugegeben: Dies wird jetzt kein fairer Vergleich! Von PureMVC bin ich begeistert - vom MATE-Framework halte ich nicht viel, außer “mal ganz Interessant einen anderen Weg zu sehen”. Leider bin ich zur Zeit in einem langfristigen Projekt an MATE gebunden. Einen Weg dieses Framework einzusetzen habe ich bereits in einem anderen Artikel in diesem Blog zusammengefasst und dabei einen ersten Vergleich zwischen MATE und PureMVC gewagt. Nun, knapp 3 Monate später hat sich mein erster Eindruck des MATE-Framework bestätigt: Es ist ein experimenteller Weg und für große Kundenprojekte einfach nicht sinnvoll! Hier eine Zusammenfassung, warum ich PureMVC immer vorziehen würde.

1. PureMVC gibt einen schlanken, sauberen Software-Entwurf vor. Dieser beruht auf bewährten Entwurfsmustern der GoF, die 1zu1 umgestzt werden. Viele Entwickler kennen diese Entwurfsmuster und können schnell in das Framework eingearbeitet werden. Zudem hat PureMVC selbst bereits eine weite Verbreitung und kann als Quasi-Standard in der professionellen Flash/Flex-Entwicklung angesehen werden. PureMVC macht Software-Entwicklung effizent! MATE hat dies alles nicht. Es gibt keine Struktur vor und jeder Entwickler bringt seinen eigenen Entwurf mit. Das Software-Design wächst so mit der Anwendung und ewig lange Einarbeitungszeiten für neue Entwickler werden notwendig. Man kann noch so viel dokumentieren, die Struktur wird garantiert nicht einheitlich.

2. PureMVC ist supergut und mehrsprachig dokumentiert - dazu kommen die unzähligen Bücher der GoF über die Grundlagen, auf denen das Framework beruht. Die Dokumentation von MATE ist noch nicht mal in Englisch akzeptabel (wobei sich dies ja ändern kann).

3. PureMVC ist übersichtlich und schlank. Bei MATE verliert man durch die MXML-Event-Map leicht den Überblick welche Instanz wann und wo zur Verfügung steht. Das MATE-Framework vollständig zu verstehen und sinnvoll einzusetzen ist möglich, aber nicht einfach - und das macht es in Kundenprojekten unprofitabel!

4. MATE referenziert Funktionen und Eigenschaften über Strings. Das hat zur Folge, dass Laufzeitfehler fliegen, die eigentlich zur Compilezeit gefunden werden sollten. Auch im Hinblick auf die Performance ist das kein guter Weg.

5. Die MATE-Kommunikation beruht auf bubbelnden Flex-Events. Aus Performance-Sicht ist das teuer. PureMVC benutzt eine vereinfachte Notification-Variante auf Basis des Observer-Pattern. Flex Events werden nur zur Kommunikation von Flex-Komponenten verwendet. Die verwendeten Flex-Komponenten sind dabei absolut lose gekoppelt und vom Framewok unabhängig.

6. Weiterhin beruht die MATE-Kommunikation auf Flex-Databinding. Flex-Databinding ist toll und praktisch, kann aber auch unübersichtlich werden, wenn alles mit allem gebunden ist. Aus Performance-Sicht ist das teuer, vor allem beim Initalisieren! PureMVC informiert das System mit Hilfe von Notifications über Zustandsänderungen.

7. Es geht schnell in MATE Objekte zu verknüpfen: Tag-basiert in MXML. Jedoch die Event-Maps so aufzubauen, dass Objekte zum richtigen Zeitpunkt bereit stehen und auch im richtigen Moment wieder den Speicher räumen, dass kostet Zeit und Nerven!

Mein Tipp: Mate trinken - PureMVC benutzen!

1. Die Klassen müssen in der RubyAMF-Config-Datei (config/rubyamf_config.rb) für das Mapping registriert werden.

2. Die Datenobjekte in Rails und Flash müssen die gleichen Attribute besitzen. Die Schreibweise in snake_case oder camelCase kann variieren, jedoch muss RubyAMF dazu entsprechend konfiguriert werden.

3. Bei ActiveRecord-Objekten muss die Datenbank-Migration ausgeführt worden sein.

4. Die ActionScript-Klassen der Datenobjekte müssen als RemoteClass registriert sein. Bei der Metatag-Variante ist darauf zu achten, dass [RemoteClass(alias="ObjectAlias")] direkt vor oder über der Klassen-Deklaration steht.

5. Die ActionScript-Klassen der Datenobjekte müssen in das Flash/Flex-Projekt importiert werden.

6. Die Klassen müssen in den ActionScript-Code importiert werden (!!!).

Das MATE-Framework soll in Flex-Anwendungen eine lose Kopplung zwischen den einzelnen Programmteilen ermöglichen. Wesentlicher Bestandteil ist eine eine so genannte Event-Map. In der Event-Map werden Flash-Events abgefangen und auf entsprechende Funktionen gemappt. Weiterhin macht sich das Framework das Prinzip der Data-Injection zunutze. Dabei werden Datenobjekte auf Basis der Flex-Datenbindung “von außen” in ein beliebiges Objekt injiziert. Unterschiedliche Objekte können auf diese Weise Daten austauschen, ohne das eine Abhängigkeit zwischen ihnen besteht. Eine weitere Besonderheit von Mate ist, dass die Event-Map ausschließlich Tag-basiert ist und mit MXML implementiert wird. Mehr Informationen zur grundsätzlichen Arbeitsweise, sowie Code-Beispiele findet man auf der MATE-Homepage unter: http://mate.asfusion.com/.

Leider ist die Dokumentation des Framework sehr lückenhaft. Besonders der “Best Practice”-Teil kommt aktuell viel zu kurz (http://mate.asfusion.com/page/documentation/best-practices), ist allerdings dringend notwendig, da Mate sehr wenig Struktur vorgibt. Das Framework unterstützt zwar eine lose Kopplung zwischen den Objekten, garantiert jedoch nicht einen sinnvollen Software-Entwurf! Da ich aktuell in einem Projekt an Mate gebunden bin, habe ich anhand einiger Beispiele auf der Mate-Webseite eine “Best Practice” herausgearbeitet, die ich nachfolgend Dokumentieren werden. Diese “Practice” orientiert sich am MVVM-Designpattern (bekannt aus MS Silverlight) und ist nur eine Möglichkeit, wie das Framework zum Einsatz kommen kann.

Noch eines Vorweg: So ganz kann ich mich mit dem Mate-Framework nicht anfreunden und auch diese “Best Practice” halte ich nicht für den Königsweg. Wer aktuell auf der Suche nach einem guten Flex-Framework ist und die freie Wahl hat, dem empfehle ich PureMVC. PureMVC gibt (nach meiner Ansicht) einen sauberen und schlanken Software-Entwurf vor. Gerade in größeren Projektteams mit wechselnden Leuten kann es vorkommen, dass beim Mate-Framework jeder Entwickler seinen eigenen Software-Entwurf mitbringt (wie gesagt: Mate unterstützt eine lose Kopplung zwischen Objekten, gibt jedoch keine einheitliche Struktur vor). PureMVC (mit einer sehr guten Dokumenation) hingegen garantiert bei richtiger Anwendung eine konsistente Umsetzung und reduziert (zwar mitunter intessante - aber zeitaufwendige) Entwurfsdiskussionen. Auch empfinde ich das Handling mit der Mate-Event-Map als unübersichtlich, was jedoch eine reine Geschmackssache sein kann. Veranschaulicht würde ich sagen: PureMVC verhält wie ein gut gewartetes Mietauto mit Navigationssystem - man steigt ein, fährt los und kommt mehr oder weniger entspannt am Ziel an. Mate ist eher der expirimentelle Weg, vielleicht wie eine weite Reise auf einem Mofa mit unvollständigen Landkarten - sicherlich sehr interessant - hin und wieder muss man mal basteln - hier und da einige Teile mit Gaffa befestigen - und immer wieder kommt der eigene Orientierungssinn zum Einsatz, der einen auch zeitweise täuschen kann.

Wie bereits erwähnt, gibt es viele Möglichkeiten mit dem Mate-Framework ans Ziel zu kommen. Eine ist die Orientierung am Model-View-ViewModel-Pattern, eine Mutation der MVC-Architektur. Der View-Teil enthält dabei eine Sammlung logikloser UI-Komponenten, die genau eine Referenz auf ein dazugehöriges ViewModel besitzen. Dieses Model sollte beim Erzeugen einer UI-Komponente über die Mate-Map in die Komponente injiziert werden. Das ViewModel enthält die Daten, die in der entsprechenden UI-Komponente dargestellt werden sollen, sowie dessen Zustände. Über Flex-Datenbindung wird die View nach einer Veränderung dieser Daten aktualisiert. Bei einer Benutzeraktion wird eine Funktion im ViewModel aufgerufen, in der die Handhabung dieser Aktion implementiert ist. Das ViewModel kann direkt reagieren und den Zustand der dazugehörigen UI-Komponente ändern (ausschließlich über Datenbindung, ohne dirkete Referenz auf die UI-Komponente). Sollte die Benutzerinteraktion weitreichendere Auswirkungen auf das gesamte System haben, kann das ViewModel ein Event senden und das System auf diese Weise informieren. In Mate werden Events in der Event-Map gefangen und auf unterschiedliche Funktionen in unterschiedlichen Objekten gemappt. Auf diese Weise kann die Event-Map Funktionen in anderen ViewModels aufrufen, die ihrerseits ein Update der dazugehörigen UI-Komponenten erwirken. Weiterhin können auch Funktionen in den Manager-Ojekten (die zum Model-Teil gehören) aufgerufen werden, die global genutzte Datenobjekte manipulieren und einen neuen Zustand der Gesamtanwendung herbeiführen. Über das Mate-Framework können diese globalen Datenobjekte in die ViewModels injiziert werden, um die View dem Anwendungszustand anzupassen. Eine Visualisierung dieses Prinzips steht als PDF zum Download bereit.

Die Besonderheit dieser Architektur stellen die zwei Arten von Model dar. Die eine Art agiert Anwendungsweit und managt global benötigte Daten und Zustände. Die andere Art hält und manipuliert die Daten und Zustände jeweils einer bestimmten UI-Komponente. Der Begriff Model umfasst in diesem Zusammenhang nicht die reinen Datenobjekte (VOs), sondern auch Fachlogik zur Manipulation dieser Daten. Der entfallende Controller aus der MVC-Architektur verteilt sich also auf die Manager(Model)- und ViewModel-Klassen. Das Mate-Framework sorgt für das Zusammenspiel der Bestandteile unter Einsatz von Events und Datenbindung (Prinzip: Data-Injection). Auf diese Weise gibt es keine Abhängigkeiten zwischen den unterschiedlichen Model-Objekten.

Um noch einmal expliziert darauf hinzuweisen: Die UI-Komponenten haben nach diesem Software-Design eine Referenz auf ihre ViewModel! Der Vorteil dabei ist, dass die UI-Komponenten leicht austauschbar sind, etwa gegen Unit-Test-Klassen. Benutzeraktionen können einfach simmuliert werden, indem Test-Routinen die Funktionen im ViewModel aufrufen und anschließend die gebundenen Daten auswerten. Der großen Nachteil ist, dass die UI-Komponenten auf diese Weise nicht universal in beliebigen Projekten genutzt werden können, sondern nur in solchen, in denen auch ViewModels zum Einsatz kommen.  Eine echte Schwachstelle(!) - sind doch gerade UI-Komponenten die Bestandteile einer Anwendung, die sich tatsächlich am ehsten zum Wiederverwenden eignen.

Zum Vergleich noch einmal PureMVC: Hier werden die UI-Komponenten völlig unabhängig vom System mit einer eigenen API entwickelt und in Mediator-Klassen verwaltet. Bei einer Benutzerinteraktion werden Events geworfen, die in Mediators gefangen werden. Die Mediators benachrichtigen das restliche System und reagieren auf Benachrichtigungen, dass sich die View verändern soll. Auf diese Weise können UI-Komponenten entwickelt werden, ohne das die Entwickler etwas über das System wissen müssen in dem ihre Komponenten zum Einsatz kommen. Für mich der bessere Weg zum Ziel.

Über andere Meinungen zum Mate-Framework, Praxiserfahrungen, THE VERY BEST PRACTICE oder Bestätigungen zu meiner Kritik als Kommentar würde ich mich freuen!

Die Projekte beschäftigen sich mit alternativen Navigationsstrukturen in Softwareprojekten. SemKingPeng ist ein Besucherinformationssystem für den Berliner Zoo, mit dessen Hilfe sich die BesucherInnen über ein Touch-Display über die Tiere informieren können. Caterpillar Garden ist eine Online-Community zur Registrierung der Population von Wanderfaltern. Die Besonderheit der beiden Projekte ist die grafische Navigation anhand der Bedeutungszusammenhänge (Semantik). Beide Projekte orientieren sich am Topic-Map-Standard. Viel Spass beim Schauen!

Übrigens bin ich begeistert von der Video-Plattform vimeo.com!!! Die Seite sieht einfach gut aus und fühlt sich auch so an. Die Usability zum Video-Upload finde ich sehr gelungen, AJAX wird sinnvoll eingesetzt und die Community-Features scheinen gut durchdacht. Auch HD-Videos werden unterstützt.

Im aktuellen Railsway-Magazin (Ausgabe 06.2009) habe ich einen Artikel veröffentlicht, in dem der praktische Einsatz von RubyAMF beschrieben wird. Insbesondere wird auf das Class-Mapping eingegangen. Durch das Class-Mapping-Verfahren ist es möglich, dass Flash-Datenobjekte direkt als ActiveRecord-Objekte im Rails-Backend zur Verfügung stehen und weggespeichert oder aktualisiert werden können.

Railsway ist ein deutschsprachiges Magazin für RubyOnRails und ist Ende 2008 erstmals erschienen. Es wird durch den Software&Support Verlag verlegt und ist an den meisten (größeren) Bahnhofskiosken erhältlich. Alternativ kann das Heft auch unter www.railsway.de bestellt werden.

Viel Spaß beim Lesen. Über Feedback unten als Kommentar würde ich mich freuen!

Mehr zum Thema:

Buch-Tipp: Peter Armstrong, Flexible Rails: Flex 3 on Rails 2

Using RubyAmf for creating a CRUD application in Rails

Using rubyamf with associations

Seitenmetaphern im WWW sind eine Verkettung einzelner Webseiten, die jeweils genau einen Zustand darstellen. Auf traditionellen Internetseiten wird bei einer Nutzeraktivität eine neue Webseite geladen, die einen neuen Zustand repräsentiert. Jede Seite und damit jeder Zustand kann durch eine URL adressiert werden. Durch den Einsatz von Flash- und AJAX-Anwendungen werden diese Seitenmetaphern durchbrochen, da die Client-Anwendungen unterschiedliche Zustände annehmen können. In solchen Anwendungen kann eine Kommunikation mit dem Server stattfinden, ohne dass die Seiten-URL wechselt. Durch diesen Umstand werden die typischen Browser-Funktionen “Seite vor” und “Seite zurück”, sowie die History-Anzeige außer Kraft gesetzt. Weiterhin können die Zustände der Anwendung nicht über eine URL adressiert oder als Bookmark gespeichert werden.

Die Adressierung unterschiedlicher Zustände kann durch die Übergabe von Parametern an die Client-Anwendung realisiert werden und wird als Deep-Linking bezeichnet. Das Open-Source-Projekt SWFAddress unterstützt durch eine JavaScript- und ActionScript-Bibliothek das Implementieren von Deep-Linking in Flash- und AJAX-Anwendungen. Durch den Einsatz von SWFAdress kann die Anwendung in die Lage versetzt werden, aufgrund von Änderungen in der URL-Leiste des Browsers den Zustand zu wechseln. Weiterhin besteht die Möglichkeit die URL durch die Anwendung zu manipulieren, sodass der jeweils aktuelle Zustand als Bookmark gespeichert werden kann.

Realisiert ist das Deep-Linking in SWFAddress mit Hilfe von HTML-Sprungmarken. Bei der Verwendung von HTML-Sprungmarken werden Änderungen in der URL durch ein #-Zeichen abgetrennt. Dies ermöglicht es die URL zu ändern, ohne einen Request zum Server zu senden und ohne einen neuen Seitenaufbau im Browser zu erwirken. Die Manipulation der URL durch die Anwendung, sowie das Reagieren auf eine URL-Veränderung übernimmt SWFAddress. Um das Framework nutzen zu können, muss es zunächst initialisiert werden. Die Initialisierung erfolgt mit Hilfe von JavaScript. Dabei wird ein Flash-Objekt angegeben, welches für die Nutzung von SWFAddress registriert wird. Weiterhin können durch JavaScript Event-Listener registirert werden, die auf Veränderungen der URL reagieren.

Für die Interaktion der Flash-Anwendung mit SWFAddress wird die ActionScript-Bibliothek des Framework als SWC-Datei in die Anwendung eingebunden. Im Anschluss steht die ActionScript-
Klasse SWFAddress zur Verfügung, über die auf die API des Framework zugegriffen werden kann. Damit die Flash-Anwendung auf Veränderungen der URL reagieren kann, können auch im Flash-Teil EventListener registriert werden. Für die Manipulation der URL steht die Funktion setValue(path:String):void zur Verfügung. Der Parameter gibt den neuen Pfad der URL nach dem #-Zeichen an, das die Sprungmarke von der restlichen URL trennt.

Auf der Webseite von SWFAddress kann man die aktuelle Version kostenlos downloaden und es ist eine ausführliche Dokumentation der API zu finden,

Sobald man jedoch das Verständnis für OOP erworben hat, rückt diese Regel stark in den Hintergrund. Man beschäftigt sich mit “sauberer” Programmierung und einer Trennung der Zuständigkeiten zwischen Darstellung, Daten und Logik (MVC-Architektur), sowie einer losen Kopplung zwischen diesen Programmteilen. Besonders merkwürdig kommt einem das Command-Pattern vor, ein durch die GoF beschriebenes Verhaltensmuster.

Das Command-Pattern (Befehls-Muster, Kommando-Muster) kapselt EINEN Befehl in ein Objekt. Bei der Umsetzung wird für jeden konkreten Befehl eine Klasse erstellt, die eine abstrakte Command-Klasse implementiert. Dabei wird genau eine Methode erstellt, die den Programmcode für den entsprechenden Befehl beinhaltet. Weitere Methoden und Attribute sind nicht vorgesehen. Eine Instanz dieser Klasse wird erzeugt, sobald der Befehl aufgerufen wird. Nach Beendigung wird diese Instanz wieder gelöscht.

Diese Vorgehensweise ermöglicht es Kommandos aus einem Programmteil aufzurufen, der keine Referenz zum restlichen System besitzt. Beispielsweise kann ein Ereignis, das auf der Benutzeroberfläche durch eine Benutzerinteraktion auftritt (z.B. Klick auf einen Button), ein solches Kommando aufrufen. Die Benutzeroberfläche benötigt auf diese Weise keine Information darüber, was durch den Aufruf genau passiert oder welche Objekte angespochen werden. Darüber hinaus ermöglicht das Command-Pattern, Befehle in einer Warteschlange abzulegen und seriell abzuarbeiten.

Eine gelungende Umsetzung dieses Entwurfsmuster findet man im Framework PureMVC. PureMVC ist ein leichtgewichtiges Framework auf Basis einer Model-View-Controller-Architektur, in dem unterschiedliche Entwurfsmuster zum Einsatz kommen. Es steht open-source als ActionScript 2+3 für Flash- und Flex-Anwendungen zur Verfügung. Weiterhin wird das Framework nach und nach in anderen Sprachen umgesetzt (Java, JavaScript, Ruby, Phyton, PHP, C#, …).

Im Framework PureMVC wird der Controller (also die Fachlogik der Software) vollständig über das Command-Pattern implementiert. Dabei wird in Simple-Commands und Macro-Commands unterschieden, wobei Macro-Commands in der Lage sind weitere Commands auszuführen. Die Kommunikation der Programmteile (M, V und C) wird über Notifications (also ein Nachrichtensystem, Observer-Pattern) realisiert. Auf diese Notifications kann ein Command gemappt werden. Dies bedeutet, sobald ein Programmteil eine Nachricht versendet, wird die Fachlogik des entsprechenden Command abgearbeitet. Auf diese Weise gibt es eine absolut lose Kopplung zwischen der Benutzerschnittstelle (GUI) und dem Model (Datenhaltung).

GoogleBooks - Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software (Gang of Four)

Homepage PureMVC

Und am 27.10.2009: Wählen Sie überwachungswütige Politiker ab und geben Sie denjenigen Ihre Stimme, die sich glaubwürdig für Freiheit statt Angst einsetzen. Die Internetseite buergerrechte-waehlen.de gibt einen Überblick darüber, wie die einzelnen Parteien mit Freiheit und Grundrechten umgehen.

Die Notwendigkeit von informationeller Selbstbestimmung habe ich im Blog-Eintrag “Informationelle Selbstbestimmung und warum doch jeder etwas zu Verbergen hat” kurz zusammengefasst!

Hoffnung machen die Grünen. In einem TV-Spot zeigen sie, wie es geht ihre Inhalte durch Unterhaltung zu vermitteln. Schon klar… Details zur Umsetzung und klare politische Forderungen kommen auch hier nicht vor, aber die Kernthemen grüner Politik werden zumindest dargestellt. Und vielleicht ermutigt ja dieser Spot den einen oder anderen die Hintergründe in langweiliger, old-school Manier in textlicher Form zu recherchieren.

Bleibt nur abschließend eine grundsätzliche Frage: Wieviel Marketingexperten und Werbestrategen in der Politik sind gut für eine Demokratie?