Update Jan 2011: Die PHP-UWA-Library wurde völlig überarbeitet und funktioniert nun mit der aktuellen IFrame-Methode. Das Prinzip bleibt das Gleiche, die Aufrufe sind leicht anders: Projekt auf oncode.info.

Widgets und Web 2.0

Widgets sind kleine Miniapplikationen, die übersichtlich wichtige Daten anzeigen oder kleinere Funktionen ausführen. Es gibt sie für Windows Vista, Mac, iPhone sowie Webbasiert für iGoogle, Yahoo!, Netvibes und so weiter und so fort. Um die Entwicklung zu forcieren, stellt nun Netvibes ein Rahmenwerk vor, das die Entwicklung von Widgets für alle diese Plattformen vereinfachen soll: Die Universal Widget Architecture. Die Widgets, die nach diesem Standard programmiert sind, sollen unter allen diesen Plattformen laufen…

UWA Standard

Ein Widget im UWA-Standard ist ein XML-Dokument. Es enthält Metadaten, Einstellungen und den aktiven Teil, geschrieben in Javascript. Besonders die Einstellungen sind interessant, denn über diese können widgetspezifische Parameter angepasst werden. Einige Toolfunktionen runden das UWA-Paket ab.

Die UWA-Spezifikation hat ihre eigene Homepage und ist gut dokumentiert. Es gibt Beispiele, ein Code-Skelett mit Erklärung, ein Schritt-für-Schritt Tutorial, ein Forum und sogar ein Cheat-Sheet. Der Einstieg wird einem wirklich so einfach wie möglich gemacht.

Widget Repository

Fertige Widgets können im Widget Repository (Ecosystem) der Öffentlichkeit zur Verfügung gestellt werden. Von diesem System aus können die Widgets zu den verschiedenen Plattformen mittels Mausklick hinzugefügt werden. Im Repository hat es auch noch Widgets, die nach dem veralteten Mini-API Standard funktionieren, diese werden jedoch (hoffentlich) bald verschwinden.

Implementationen

Das klingt echt faszinierend und schreit danach, genutzt zu werden. Widgets selbst werde ich später implementieren, als erstes wollte ich sie wirklich für eigene Projekte nutzbar machen. Dafür habe ich eine kleine PHP- Klasse entworfen und sie grosskotzig PHP-UWA Widget Library genannt. Mit ihr ist die Handhabung von Widgets ziemlich einfach. Etwas ambitionierter ist das Parsing der widgetabhängigen Einstellungen.

Ein Minimalbeispiel ist im Download-Paket dabei und kann auch online aufgerufen werden.

Ein Widget anzuzeigen geht recht fix:

Informationen über das Widget (sobald die URL angegeben wurde) geben die folgenden zwei Methoden:

getMetaData()

Metadaten wie Autor, Keywords, Beschreibung, … Siehe Doku.

getAdditionalData()

Zusätzliche Daten wie Icon, Stylesheet, …

Grundsätzlich gibt folgende Einstellungsbereiche:

general

Die URL zum Widget.

configuration

Anzeigeparameter, die in der Doku beschrieben sind.

preferences

Widgetabhängige Einstellungen, die ebenfalls in der Doku erwähnt sind.

Zu allen diesen Einstellungen gibt es folgende Methoden:

Setters und Getters

setModuleUrl(), setConfiguration(), setPreferences()

getModuleUrl(), getConfiguration(), getPreferences()

getSettingsFormData($section)

Gibt die Settings in einem lesefreundlichen Array wieder, aus welchem ziemlich einfach ein Form generiert werden kann. $section ist dabei "general", "configuration" oder "preferences"

getSettingsHTML($section)

Gibt die Settings in Array der Form "Label" => "HTML" zurück. $section ist dabei "general", "configuration" oder "preferences"

Zum Test habe ich Moodleblock erstellt, welcher nun die Darstellung von UWA-Widgets innerhalb des LMS erlaubt. Heyo, WordPress, Xoops, etc-Coderz, wie wärs bei Euch mit einer UWA Integration???

Beispiele vom Moodleblock:

Die Konfiguration unter Moodle:

Ui, fast…

…wäre ich schneller als das aktuelle c’t gewesen, welches eine gute aber knappe Einführung in UWA-Widgets enthält.

In einem älteren Posting habe ich schon beschrieben, dass wir das LMS Moodle mit SVN integrieren. Um die Integration voranzutreiben habe ich einen Block gecoded, von welchem aus man direkt die Dateien aktualisieren kann:

Den Code zu posten macht nicht viel Sinn, da es sehr installationsabhängig ist. Auf Anfrage hin rücke ich aber gerne was raus ….

Moodle eignet sich sehr gut um Dokumente für Lernende bereitzuhalten und zu publizieren. SVN eignet sich, um Dokumente abzulegen wenn mehrere Leute zusammenarbeiten. Was liegt also näher als die beiden Dinge zu kombinieren?

Vorteile:

• Es sind immer aktuelle Dokumente auf dem Moodle
• Das lästige Hochladen entfällt
• Es ist mächtig 1337!

Soweit die Theorie, doch wie läuft das in der Praxis?

Grundsätzlich werden auf dem Moodleserver die SVN-Verzeichnisse ausgecheckt. Jede Nacht läuft ein Cronjob, der diese Arbeitsverzeichnisse aktualisiert und noch nicht vorhandene an diesen Ort auscheckt. Im Moodle “data” Verzeichnis werden in den Kursen symbolische Links auf diese Arbeitsverzeichnisse gesetzt, die dann in Moodle selber wie normale Verzeichnisse behandelt werden können.

Um diese Arbeitsverzeichnisse auszuchecken habe ich ein Bash-Script geschrieben, für das Setzen der Links gibt es ein ganz hässliches Webinterface. Beide Quellcodes stelle ich gerne zur Verfügung, hierhin passense nicht….

Probleme:

• Die Berechtigungen der Arbeitsverzeichnisse müssen so gesetzt werden, dass normale Benutzer über Moodle keine Dateien verändern oder löschen können.
• Da es ein Link ist und kein echtes Verzeichnis, lässt Moodle keine “Verzeichnis Ressourcentypen” zu. Korrigiert werden kann dies in lib/moodlelib.php, Funktion get_directory_list:
  if (!is_dir($rootdir)  && !is_link($rootdir)) {          // Must be a directory

  und:

  if (filetype($fullfile) == 'dir'  || filetype($fullfile) == "link") {
• Die SVN-Arbeitsverzeichnisse sollen ja nicht migebackupt werden, da man gescheiter die Repositories sichert. Darum in backup/backuplib.php, Funktion backup_copy_course_files anpassen:
  if ($dir !== $name_moddata and $dir !== $name_backupdata and !is_link($rootdir."/".$dir)) {