Die in diesem Artikel vorgestellten Technologien können und sollen weder PHP noch TYPO3 ersetzen. Vielmehr geht es um einen Ausblick auf neue Entwicklungen, die sich aus dem Hype um das so genannte Web 2.0 abheben. Vielleicht sind einige von ihnendem einen oder anderen eingefleischten TYPO3-Experten bisher vorenthalten geblieben.

Ruby on Rails ist ein auf der Skriptsprache Ruby basierendes quelloffenes Framework zur Erstellung von Webapplikationen. Version 1.0 wurde im Dezember 2005 von David Heinemeier Hansson unter der MIT-Lizenz [1] veröffentlicht. Die wachsende Gemeinde von Entwicklern um Hansson versucht seitdem, moderne Architekturmuster umzusetzen: dazu zählen die konsequente Anlehnung an Model-View-Controller (MVC) mit dem Ziel, eine einfache Wiederverwertbarkeit von Komponenten zu ermöglichen (Stichwort: DRY). Die Reduzierung auf ein Mindestmaß an Komplexität soll dem Entwickler mehr Zeit und Raum geben, sich auf das Wesentliche zu konzentrieren. Die Installation von Rails ist auf der Website von Ruby on Rails ausführlich beschrieben und einige Dienstleister bieten inzwischen das Hosting von Rails an [2].

Rails kommt im Gegensatz zu XML-Frameworks mit einer einzigen Konfigurationsdatei zur Einstellung der Datenbankparameter aus (Convention over configuration). Unterstützt werden zahlreiche RDBMS wie PostgreSQL, Oracle, MySQL und auch das leichtgewichtige SQLite. Der Entwickler braucht sich dabei nicht um die Unterschiede und Eigenheiten der verschiedenen Datenbanken kümmern – Rails bildet die Struktur der Datenbank einheitlich und transparent ab. Ein „Scaffolding“ (zu deutsch „Baugerüst“) genannter Mechanismus erzeugt entsprechend der Felder und deren Typen automatisch prototypischen Programmcode und HTML-Templates, die im Laufe der Entwicklung durch eigenen Code und eigenes Design ergänzt werden. Besonders für Einsteiger kann ein solches Grundgerüst eine Erleichterung darstellen, aber auch Profis profitieren von der eingesparten Tipparbeit.

Die Erweiterbarkeit von Rails ist eine große Stärke des Frameworks: eine Bibliothek von Ruby-Modulen steht bereit, um auch bei exotischen Problemstellungen auf einen eigenen, möglicherweise aufwendig zu implementierenden Ansatz verzichten zu könnnen. Mit „Ruby Gems“ können Module hinzugefügt, entfernt und automatisch aktualisiert werden, ähnlich dem von Debian bekannten „apt-get“ oder „CPAN“ bei Perl. Die Palette reicht von einem Modul zur Anbindung an Jabber/XMPP (XMPP4R) über Schnittstellen zu Betriebssystemen („dbus“ für MacOSX und Linux; „com32api“ für Windows) bis zu Erweiterungen für den Funktionsumfang von Rails selbst – zum Beispiel ein alternativer Scaffolding-Mechanismus der JavaScript-Code für AJAX generiert. Auf einem Betriebssystem mit installierten Ruby Gems reicht der Befehl

gem install ajax_scaffold_generator

um ihn zu installieren. Ähnlich einfach ist die Vorgehensweise, um auf eine neue Version von Rails zu springen:

gem update rails

Abhängigkeiten zu bestehenden Modulen werden dabei automatisch aktualisiert. Änderungen an Rails, die die Struktur der Datenbank betreffen, werden ebenfalls automatisch eingepflegt – auf Werkzeuge wie phpMyAdmin kann der Rails-Administrator verzichten.

Der integrierte und plattformunabhängige Webserver (Webrick) beschleunigt die Entwicklung im Sinne des „Agile Software Development“ weiter. Aber Rails-Anwendungen lassen sich auch auf eigenständigen Webservern ausführen: Apache (mit oder ohne „mod_ruby“) und lighttpd (mit „FastCGI“ oder dem modernen „SCGI“) sind die verbreitetsten Ansätze. Steigender Beliebtheit erfreut sich der in Ruby implementierte Webserver Mongrel, der einige spezielle Möglichkeiten in Verbindung mit Rails bietet.
Um eine neue Rails Applikation zu erstellen und Webrick zu starten genügen folgende Befehle:

rails myRailsApp
cd myRailsApp
ruby script/server

Mit RadRails steht eine ebenfalls quelloffene und auf Eclipse basierende Entwicklungsumgebung bereit. RadRails verträgt sich auch mit anderen Eclipse-basierten IDE: ein gutes Beispiel ist Adobe Flex 2.0.

Am 10. März 2004 veröffentlichte Macromedia die erste Version von Flex. Im Gegensatz zum zu diesem Zeitpunkt bereits etablierten Flash 2004 MX ist Flex weniger ein Werkzeug für Webdesign und Animation als zur Entwicklung von eigenständigen Applikationen. Macromedia reagierte damit auf die Abneigung vieler Entwickler, einen Design-orientierten Ansatz in den Mittelpunkt der Arbeit zu stellen.

[3] dient dazu, durch den Flex Compiler in das von Flash gewohnte Format SWF zu übersetzen. Die Voraussetzungen des Clients für Flex beschränken sich daher auf einen installierten Flash Player. Hier ein Beispiel für das Abspielen von Flash Videos in MXML:

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:VBox>
		<mx:VideoDisplay id="myVid" source="http://localhost/video/MyVideo.flv" />
		<mx:Button label="Pause" click="myVid.pause();" />
		<mx:Button label="Play" click="myVid.play();" />
	</mx:VBox>
</mx:Application>

Kurz nach der Übernahme von Macromedia durch Adobe erschien die Version 2.0 von Flex, die im Vergleich zu den früheren Versionen deutlich weiterentwickelt wurde. Während die IDE nun auf Eclipse basiert und weitreichende Möglichkeiten zum Debugging bietet (für Flash-Entwickler oftmals ein unangenehmes Unterfangen), hat sich die Plattform vielen Standards geöffnet und sich von den properitären Ansätzen (zum Beispiel zur Anbindung externer Datenquellen) entfernt. Verbreitete Standards wie XMLRPC, SOAP, JSON und nicht zuletzt AJAX werden unterstützt.

Eine wichtige Neuerung ist die Unterstützung von ActionScript 3.0. Entwickler, die bisher eine konsequente Objektorientierung vermisst haben, können jetzt aufatmen, denn ActionScript ist erwachsen geworden und wartet mit zeitgemäßen Konzepten auf: Nahezu die gesamte Funktionalität von Flex ist durch ActionScript an die eigenen Bedürfnisse anpassbar. In bester objektorientierter Manier lassen sich Klassen erweitern und durch eigene Ergänzen. Auch das aus Java bekannte Konzept der „Packages“ hat Einzug gehalten.

Um die Zusammenarbeit zwischen Designern und Entwicklern zu vereinfachen, hat Adobe mit Version 2.0 das von HTML gewohnte CSS in alle Funktionen von Flex integriert. Sollten die damit verbundenen Möglichkeiten zur Gestaltung noch nicht ausreichen, ist eine andere Neuerung interessant: Das „Skinning“. Ein Designer kann nun in Flash Designvorlagen erstellen, die in Flex eingebunden werden. Dadurch sind dem Erscheinungsbild der Applikation kaum noch Grenzen gesetzt und die angestrebte Trennung zwischen Code und Design ist noch deutlicher vollzogen.

Die Dokumentation von Flex ist in Version 2.0 nahezu vollständig überarbeitet worden und taugt nun auch für Umsteiger und Neulinge. Adobe selbst bietet mittlerweile eine Vielzahl von Tutorials und Videocasts an und die Mitarbeiter schreiben zu relevanten Themen fleißig Blogs – eine lebendige Gemeinde ist enstanden, sicher nicht zuletzt wegen des neuen Lizenzmodells: Zumindest ist der Compiler von Flex 2 (Flex SDK) nun kostenlos erhältlich (die IDE „Adobe Flex Builder 2“ kostet derzeit 749 US-Dollar).
Eigene kommerzielle Interessen haben so eine Chance bekommen: Die Binärkompilate (SWC) von selbstentwickelten Flex-Komponenten lassen sich vertreiben, ohne Einsicht auf den Quellcode gewähren zu müssen. Der Kunde bindet diese Komponenten als „Black-Box“ in seine Applikation ein und zahlt – ein noch neuer Markt, den aber bereits einige kleine Unternehmen für sich entdeckt haben. Entwickler, die ihre Komponenten als Open Source anbieten möchten, finden bei Adobes „Flex Exchange“ eine passende Plattfom.

Es stellt sich die Frage, was Rails und Flex miteinander verbindet. Flex eignet sich besonders zur Erstellung interaktiver, graphisch anspruchsvoller Oberflächen. Rails zeichnet sich durch die bereits beschriebenen, vielseitigen Möglichkeiten zur Bildung von Schnittstellen (z. B. zwischen Datenbanken und Applikationen) bei minimalem Aufwand aus.

Die auch von TYPO3 bekannte Trennung zwischen dem Backend – der Datenquelle – und dem Frontend – dem Präsentationsserver – zieht sich quer durch das Web – aus guten Grund. Daten können und sollen sich ändern dürfen, gleiches gilt für das optische und funktionale Erscheinungsbild der Applikationen. Viele Entwickler kennen folgendes Problem: Ein Projekt begann einfach, als Datenquelle reichte SQLite oder MySQL. Doch mit steigenden Anforderungen offenbaren sich Probleme. Schlecht implementierte Schnittstellen oder überforderte Datenbanken sorgen oftmals für zeitaufwendige Korrekturen.

Rails und Flex bieten in Kombination mit einem dritten Kandidaten ein ausgezeichnetes Beispiel, wie man derartige Probleme vermeiden kann: WebORB [4] von der Firma Midnight Coders liegt seit August 2006 in Version 1.0 als Plugin für Rails vor, liezensiert unter der GPL. WebORB bietet eine interessante Alternative zu den „Adobe Flex Data Services 2“, deren Lizenz zur Entwicklung kommerzieller Anwendung derzeit um die 6.000 US-Dollar kostet.

Die Installation des Plugins ist simpel:

cd myRailsProject
ruby script/plugin install http://themidnightcoders.net:8089/svn/weborb

Eine detaillierte Anleitung zur Installation und Konfiguration von WebORB findet sich auf den Seiten von Midnight Coders [5].

Die Möglichkeit, via HTTP zu kommunizieren, bietet Flex bereits von Haus aus, ein paar Zeilen MXML reichen aus, um mit einer Webapplikation Verbindung aufzunehmen. WebORB bildet eine Schnittstelle zwischen Flex und Rails und verknüpft Frontend und Backend. Mittels dem aus Flash bekannten Kommunikationsprotokoll AMF (einigen Lesern wird auch AMFPHP ein Begriff sein) stellt es eine Verbindung zum Framework von Rails her, wodurch ein Zugriff auf die Funktionen von Rails und den darunterliegenden Ruby-Modulen ermöglicht wird.
Mittels einer Konfigurationsdatei werden WebORB die Methoden bekannt gemacht, die anschließend aus Flex aufgerufen werden können – ein Zugriff auf sicherheitskritische Bereiche des Rails Frameworks ist nicht möglich, es sei denn der Entwickler gibt ihn explizit frei. Nebenbei kümmert sich WebORB um das Serialisieren und Typisieren der Daten und das Abfangen von Fehlern.

<!-- WebORB remoting-config.xml -->
<destination id="InfoService">
	<properties>
		<source>InfoService</source>
	</properties>
</destination>

require 'weborb/context'
require 'rbconfig'

class InfoService
	def getComputerInfo( requestId )
		computer_info = Hash.new
		request = RequestContext.get_request
		computer_info['serverName'] = request.server_software
		computer_info['requestId'] = requestId
    		computer_info['os'] = Config::CONFIG["arch"].to_s
    		computer_info['currentTime'] = Time.now
    		computer_info
  	end
end

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="onCreationComplete();" >

	<mx:Script>
		<![CDATA[
			import mx.controls.Alert;
			import mx.rpc.events.ResultEvent;
			import mx.rpc.remoting.mxml.RemoteObject;
	
			private var remoteObject : RemoteObject;
	
			private function onCreationComplete():void
			{
				remoteObject = new RemoteObject();
				remoteObject.destination = "InfoService";
				remoteObject.getComputerInfo.addEventListener( "result", onResult );
			}
	
			private function onResult(event:ResultEvent):void
			{
				var computerInfo:Object = event.result;

				serverInfoText.text = computerInfo.serverName;
				osText.text = computerInfo.os;
				timeText.text = computerInfo.currentTime.toString();

				infoButton.enabled = true;
			}
	
			private function getInfo():void
			{
				infoButton.enabled = false;
				
				serverInfoText.text = "in progress ...";
				osText.text = "in progress ...";
				timeText.text = "in progress ...";

				remoteObject.getComputerInfo( "request2342" );
			}
		]]>
	</mx:Script> 

    <mx:TitleWindow width="580" height="382" layout="absolute" title="TYPO3 Magazine" horizontalAlign="left" fontFamily="Verdana">
        <mx:Panel x="10" y="10" width="540" height="290" title="WebORB Test" backgroundImage="assets/ruby.png" horizontalAlign="center" verticalAlign="middle" backgroundColor="#c0c0c0">
               <mx:Label text="Results" height="20" />
           		<mx:Panel title="serverInfoText"  width="510" height="62">
					<mx:Text id="serverInfoText"  text="waiting for result" />
				</mx:Panel>
           		<mx:Panel title="osText"  width="510" height="62">
					<mx:Text id="osText" text="waiting for result" />
				</mx:Panel>
           		<mx:Panel title="timeText"  width="510" height="62">
					<mx:Text id="timeText" text="waiting for result" />
				</mx:Panel>
        </mx:Panel>
        <mx:Button id="infoButton" label="Get Server Info" click="getInfo();"  x="10" y="310"/>
    </mx:TitleWindow>

</mx:Application>

Mit dem Einsatz von WebORB ist es für den Entwickler nicht mehr entscheidend wo und von welcher Technologie die Methoden ausgeführt werden. WebORB eignet sich daher insbesondere zur Konsolidierung von Datenquellen. Der Entwickler braucht sich keine Gedanken über die Art und Weise derselben zu machen. Er bekommt einheitliche Ergebnisse, selbst wenn mehrere verschiedene Datenbanken verwendet werden. Die gesparte Zeit kann nun der Applikation zugute kommen. Letztendlich werden sich die Kunden weniger über die Technologien „unter der Haube“ freuen, als über eine liebevoll gestaltete Flex-Applikation, die weitgehend ohne Fehlermeldungen auskommt.

Der Autor

Tom Hensel wohnt in Hannover und ist seit Ende der Neunziger Jahre in den Bereichen Entwicklung, UNIX-Systemadministration und Embedded Appliances aktiv. Nach langjähriger Tätigkeit als Freiberufler ist er jetzt im Team von MACINA interactive media (www.macina.com) gelandet und dort hauptsächlich mit der Entwicklung von Flex-Applikationen und der Administration des Firmen-Netzwerks beschäftigt.