web and variants | 2009

25. November

Redaxo: Templates, Module & Actions mit RexSync Synchronisieren

Auf dem Redaxo-Day haben einige Teilnehmer Interesse an unserer Lösung für dateibasiertes Arbeiten mit Templates und Modulen geäußert. Aus diesem Grund haben wir uns nun entschieden, ein kleines Tutorial zu veröffentlichen, damit andere Redaxo-Entwickler sich ebenfalls dieser komfortablen Funktion bedienen können.

Idee

Wir setzen recht viele Projekte auf Basis von Redaxo um, so dass es viel Zeit kostet, Module, Templates und Aktionen ständig per Copy-Paste in das Redaxo Backend zu übernehmen. Außerdem arbeiten wir mit Versionskontrollsystemen (SVN, Mercurial), so dass dateibasiertes Arbeiten für uns notwendig ist. Aus diesem Grund haben wir ein Skript entwickelt, das Dateien für Templates und Module automatisch mit der Datenbank synchronisiert. Da die meisten unserer Entwickler mit Eclipse arbeiten, lässt sich das Script als Builder installieren, so dass beim Speichern der Datei in Eclipse automatisch die aktuelle Dateiversion in die Datenbank gespielt wird. Letztlich kann man das Script allerdings auch im Browser aufrufen oder durch irgendein anderes Tool zur Dateisystemüberwachung automatisch aufrufen.

Das Script liest alle nötigen Parameter aus einem speziellen Dateiheader aus. So wird bei Templates z.B. die ID oder der Templatename im Header definiert. Außerdem kann man die CTypes angeben, die von diesem Template unterstützt werden. Außerdem gibt es eine kleine Konvention für Dateinamen, um die richtigen Files schnell zu finden.

Dateisystem

Wir haben uns eine kleine Konvention im Dateisystem überlegt, wo Module, Templates und Actions gespeichert werden müssen, um weniger Konfigurationsaufwand zu haben. Selbstverständlich kann man das auch durch Anpassen des Scripts auch problemlos ändern.

Im Hauptverzeichnis des Projekts erwarten wir ein Verzeichnis develop. Darunter jeweils ein Verzeichnis templates, modules und actions – sofern Aktionen genutzt werden. Der Verzeichnisbaum sieht dann also wie folgt aus:

/develop
  /actions
  /modules
  /templates
/files
  /...
/redaxo
  /...
...

Templates

Das Script erwartet einen speziellen Header für ein Template. Dieser Header hat diverse Optionen, um möglist nichts mehr im Backend machen zu müssen. Ein Template könnte wie folgt aussehen:

<?php
/*
 * @rex_param      id      10
 * @rex_param      name    Standard
 * @rex_param      active  1
 * @rex_attribute  ctype   array(1 => "Linke Spalte", 2 => "Mittlere Spalte")
 */
 
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>webvariants Rules</title></head>
<body>REX_ARTICLE[1]</body>
</html>

Dieser Template Header definiert ein aktives Template mit der ID 10 und dem Templatenamen Standard. Außerdem werden zwei CTypes definiert. Hier kann man sehen, dass wir es vermieden haben eine komplexe Syntax zu definieren. Letztlich erwartet der Parameter ctype einfach ein Array, mit den IDs der CTypes als Key und den Namen der CTypes als Value.

Parameter

@rex_param id: ID des Templates als int. Muss über alle Templates eindeutig sein.
@rex_param name: Name des Templates. Es ist sinnvoll, aber nicht notwendig, dass dieser Wert eindeutig ist.
@rex_param active: 1 oder 0. 1 wenn das Template aktiv sein soll, also dem Nutzer zur Auswahl zur Verfügung stehen soll. 0 für inaktive Templates.
@rex_attribute ctype: Array mit den IDs der CTypes als Key und den Namen der CTypes als Value.

Dateinamen

Neben den Parametern haben wir noch eine Konvention für die Dateinamen der Templates. Standardmäßig muss jedes Template auf .template.php enden.

Bei uns im Unternehmen erhalten die Templates außerdem die ID und eine Abwandlung ihres Namens im Dateinamen. So könnte das obige Beispieltemplate 10_standard.template.php heißen. Allgemein geben wir aktiven Templates gerne zweistellige IDs und inaktiven Templates gern dreistellige. Das hilft, den Überblick zu behalten. Mit Nummernbereichen für verschiedene Arten von Templates kann man so auch gut Sammlungen von Templates anlegen, die man dann einfach in das jeweilige Projekt kopieren kann. Da die IDs so global vergeben werden können, kann man sich eine Menge Arbeit sparen.

Module

Module funktionieren entsprechend der Templates. Auch hier ist ein spezieller Header für die Parameter zuständig. Ein wichtiger Unterschied: Ein Modul kann bis zu zwei Dateien haben. Je eine Datei für Moduleingabe und eine für die Modulausgabe. Die Files sind allerdings optional. Hat ein Modul z.B. nur eine Eingabe oder nur eine Ausgabe, ist auch nur diese Datei nötig. Sind beide Modulfiles vorhanden (was wohl der Standardfall sein dürfte), sind die Header redundant. Es ist allerdings nötig sie in beiden Modulfiles anzugeben, da sie unabhängig voneinander synchronisiert werden.

<?php
/*
 * @rex_param  id    20
 * @rex_param  name  HTML-Code
 */
 
..... MODULINHALT .....
?>

Dieser Modul-Header definiert ein Modul mit ID 20 und dem Modulnamen HTML-Code. Wichtig ist, dass Moduleingabe und Modulausgabe den gleichen Header erhalten, wenn beide vorhanden sind.

Parameter

@rex_param id: ID des Moduls als int. Muss über alle Module eindeutig sein.
@rex_param name: Name des Moduls. Es ist sinnvoll, aber nicht notwendig, dass dieser Wert eindeutig ist.
@rex_param actions: Array mit IDs von Actions, die diesem Modul zugeordnet werden sollen. z.B. @rex_param actions array(1)

Dateinamen

Auch für Module gibt es eine Konvention für die Dateinamen. Eingabemodule enden auf .input.module.php, Ausgabemodule auf .output.module.php.

Wie auch bei den Templates erhalten bei uns im Unternehmen Module außerdem ihre ID und ihren Namen (ggf. in abgewandelter Form) im Dateinamen. Z.B. 020_html.input.module.php bzw. 020_html.output.module.php.

Actions

Auch wenn wir Actions eher selten benutzen haben wir auch Unterstützung für Actions eingebaut. Sie ist analog zu den Modulen und Templates.

<?php
/*
 * @rex_param  id      1
 * @rex_param  name    Rexnames
 * @rex_event  ADD     1
 * @rex_event  EDIT    1
 * @rex_event  DELETE  0
 */
 
..... INHALT DER ACTION .....
?>

Dieser Code definiert die Action “Rexnames” mit der ID 1. Wie bei Modulen werden die verschiedenen Aktionstypen (Presave, Postsave, Preview) in verschiedene Dateien gelegt. Allerdings kann sich der Header hier unterscheiden. Die rex_event Parameter können für jede Teilaction angeben, zu welchem Ereignis sie aufgerufen werden soll.

Parameter

@rex_param id: ID der Action als int. Muss über alle Actions eindeutig sein.
@rex_param name: Name der Action. Es ist sinnvoll, aber nicht notwendig, dass dieser Wert eindeutig ist.
@rex_event ADD,EDIT,DELETE: 1 wenn der Event die Aktion auslösen soll, sonst 0. Es sollte für alle drei Events je ein Wert angegeben werden.

Dateinamen

Auch bei Actions gibt es eine entsprechende Konvention für die Dateinamen: .presave.action.php, .postsave.action.php und .preview.action.php

Bei uns im Unternehmen könnte eine Action also so heißen: 1_rexnames.postsave.action.php

Das Script: RexSync

Nachdem nun Templates, Module und Actions einfach definiert werden können, fehlt eigentlich nur noch das Script, um den ganzen Spaß zu synchronisieren. Das Script selber muss einfach ins Hauptverzeichnis des Projekts gelegt werden. Sobald das Redaxo installiert ist, kann es sich aus der Redaxo Konfigurationsdatei master.inc.php selbständig die Datenbankkonfiguration auslesen und die Synchronisation vornehmen.

Download des RexSync Scripts

ACHTUNG: Das Script ist destruktiv. D.h. es macht keine echte Synchronisation. Änderungen in der Datenbank werden ohne Rückfrage überschrieben. Außerdem löscht das Script keine Inhalte. Wer also ein Modul oder Template los werden möchte, muss das von Hand im Backend oder der Datenbank tun. Umbenennen ist hingegen kein Problem. Die Einträge werden über ihre ID identifiziert, so dass Namensänderungen übernommen werden.

Info: RexSync überprüft den synchronisierten Code als kleine Unterstützung noch auf Syntaxfehler. Sollte ein Fehler im PHP-Code auftreten, wird dieser in der Konsole ausgegeben und die Synchronisation abgebrochen.

Ab hier kann man mit dem Script gut arbeiten. Wer das Script auf seinen Server läd, kann auch dort sehr einfach per FTP aktualisierte Templates, etc. in die Datenbank synchronisieren. Wir empfehlen durch ein Addon wie unser SlimMenu, die Navigationspunkte “Module” und “Templates” aus dem Redaxo Backend auszublenden, um nicht versehentlich dort Änderungen zu machen, die dann durch RexSync wieder überschrieben werden.

Im Folgenden erklären wir noch, wie RexSync in Eclipse als Builder eingesetzt werden kann. So kann es vollautomatisch ablaufen, und man muss die Dateien nur noch anlegen und bearbeiten.

Eclipse Builder

Wer RexSync als Eclipse Builder installieren möchte, sollte zuerst einmal in Eclipse die zwei Variablen “PHP_INI” und “PHP_PATH” setzen. Hierfür müssen die Variablen in den Preferences eingesetllt werden:

Window -> Preferences -> Run/Debug -> String Substitution

Dort einfach über “New” die Variablen erstellen:
PHP_INI: pfad/zur/php.ini
PHP_PATH: pfad/zur/php/installation/

ACHTUNG: Bei PHP_INI muss der Pfad einschließlich der ini-Datei angegeben werden. Bei PHP_PATH muss der Pfad zur php.exe ohne diese angegeben werden, mit Slash / am Ende.

Nachdem die Variablen angelgegt sind, muss nur noch der Builder in Projekt erstellt werden:

Kontextmenü des Projekts -> Properties -> Builders

Nach einem Klick auf “New”, wählt man “Program” aus.

Im folgenden Dialog sind folgende Angaben zu machen:

Name: RexSync
Location: ${PHP_PATH}\php.exe
Working Directory: ${build_project}
Arguments: -c ${PHP_INI} "${build_project}\rex_sync.php"

Nachdem diese Einstellungen im Main-Tab vorgenommen wurden, bitte noch einen kurzen Blick auf den Tab “Build Options” werfen und folgende Optionen aktivieren:

Allocate Console (necessary for input)
After a “Clean”
During manuals builds
During auto builds

Außerdem sollte auf der Buil Options seite ein Workingset für den Builder angegeben werden. Hier einfach über Specify Resources… in dem aktuellen Projekt das develop-Verzeichnis auswählen. So wird der Builder wirklich nur aufgerufen, wenn sich in diesem Verzeichnis etwas getan hat.

Nach Abschließen des Dialogs muss der Builder noch durch das Häkchen davor aktiviert werden und schon steht der vollautomatischen Synchronisation nichts mehr im Wege.

Wer Fragen hat, darf hier immer gern Kommentare schreiben. Auch Mails sind natürlich herzlich willkommen. – Viel Spaß mit RexSync!

Links:

10. November

Fundsachen: Kommunikation 2.0

von Wolf Brüning Kommentieren

Eine wirklich schöne Infobox in einem Fachmagazin (entdeckt von Miri):

Please dont contact

Hä???

Frei nach dem Motto „ich geb Dir meine Kontaktdaten nur, wenn Du mich in Ruhe lässt.“

10. November

Kleine Freuden und Ärgernisse des Alltages

von Christian Metzeler 2 Kommentare

Eine Freude, die erwähnt werden sollte, hat mir Thomas Meyer vom zws-blog gemacht, als er mir eine Einladung zum heiß begehrten Google Wave geschickt hat. Da hab ich dann am Wochenende auch gleich ein wenig drin gestöbert. Allerdings: ohne Freunde und Bekannte, mit denen man waven könnte, ist die Sache noch ganz schön unspektakulär. Interessant wird Wave mit Sicherheit erst, wenn viele Personen mit dabei sind, die man kennt und man sich auch tatsächlich unterhalten kann. Wir haben jedenfalls geplant, Wave nach Möglichkeit bei uns intern zu installieren und dann als produkte Kommunikationsform einzusetzen. Schaun wir mal, ob Wave dann tatsächlich hält, was es verspricht.

Und ein Ärgernis soll auch erwähnt werden: pünktlich einen Monat nach dem Auslaufen der Garantie meines iPhones hat der – relativ lebensnotwendige – Home-Button seinen Dienst eingestellt. Da man ohne den Home-Button so gut wie keine einzige iPhone-Applikation schliessen kann, ist das Gerät damit eigentlich funktionsuntüchtig geworden. An einen Jailbreak, um die Funktion des Buttons via Software zu erschliessen, habe ich mich nicht rangetraut. Außerdem benötigt man den Button auch noch für den bisweilen notwendigen Restart des Geräts. Und die diversen iPhone-Reparaturdienste, die es so im Land gibt, sind ebenfalls nicht die günstigsten und im Zweifelsfall weiß man einfach nicht, was die mit dem Gerät tatsächlich anstellen. Daher habe ich bei Apple einen Austausch bestellt, der mit fröhlichen 239,90 Euro für mein 3G-Phone mit 16 GB zu Buche schlägt. Denn bei Apple tauscht man dem Kunden nämlich nicht einfach nur das Flexband-Kabell unter dem Button aus, das man für ein paar Euro im Ersatzteilladen bekommt. Nein, bei Apple bekommt man gleich ein neues iPhone und schickt das alte zurück.
Mein Fazit: bei Apple kaufe ich nichts mehr. Mir gefällt die rigide Unternehmenspolitik nicht, die Preispolitik gefällt mir auch nicht und die Unflexibilität finde ich auch schlecht. Das einzig Gute ist, dass das neue Fon bereits gestern morgen (Montag) auf meinem Tisch lag, nachdem ich den Schaden am Freitagmorgen gemeldet und den Austausch beantragt habe. Das ging wirklich schnell. Insgesamt gilt: sobald ein Fon dem iPhone in Technik und Umgebung gleichzieht, hole ich mir lieber das. In den zwölf Jahren, die ich mit Nokias Communicatoren verbracht habe, habe ich nicht annähernd soviel Kosten gehabt, wie in einem Jahr mit dem iPhone und seinen Schäden. Apple ist eher was Gläubige, als für mündige Menschen.

das Original Apple iPhone-SIM-Kartenslot-Öffnungstoolkit - peinlicher gehts echt nicht.

6. November

Vergleich aktueller JavaScript-Compressoren

von Christoph Kommentieren

Nachdem Google heute seine eigene JavaScript-Suite namens Closure Tools veröffentlicht hat, war es nur sinnvoll, den enthaltenen Compressor (“Google Compiler”) mit den anderen verfügbaren zu vergleichen.

Die Kandidaten

Der Einfachheit halber konzentrieren wir uns auf die großen fünf:

Google Compiler (The New Kid on the Block) (Java)
YUI Compressor (unser bisheriger Standard-Offline-Packer) (Java)
Dojo Shrinksafe (eher unbekannt in unserem Umfeld (REDAXO)) (Java)
JSmin (nutzen wir im Deployer, um live via PHP JavaScript zu komprimieren) (C)
Packer (Web-Tool, wir nutzten den PHP-Port)

Die Aufgaben

Zu Testzwecken haben wir alle fünf Programme mit zwei unterschiedlichen Eingabedateien befeuert:

Eine Sammlung eigenen Codes, den wir für varisale nutzen. Nicht komprimiert, dafür aber kommentiert und mit viel Whitespace.
Eine Zusammenstellung von jQuery, jQueryUI und jsTree, alle drei bereits minimized.

Schauen wir uns mal an, wie das Ergebnis aussieht.

Ergebnis für eigenen, unkomprimierten Code

Ergebnis für bereits komprimierten Code

Fazit

Wir sehen, dass selbst bei vermeintlich schon komprimiertem Code durchaus noch etwas herauszuholen ist. Das gute Abschneiden des Packers lässt sich damit begründen, dass auch im zweiten Test neben den genannten großen Bliotheken auch noch kleinere Plugins (jQuery Cookie, Table Drag’n'Drop) enthalten waren, deren Code noch nicht optimiert war.

Bleibt die Frage nach der Performance des Packers. Immerhin wird der Code nicht mehr plain ausgeführt, sondern durch eval() geschleust, was nicht nur seine Ausführungsgeschwindigkeit, als auch die Debugging-Fähigkeit reduzieren dürfte. Natürlich entfernen auch die anderen Programme die Variablennamen und ersetzen sie durch möglichst kurze Buchstabenfolgen, aber immerhin bleibt der grobe Kontrollfluss erhalten.

Der Google Compiler hat sich übrigens an einer Stelle in dem zweiten Test beschwert, dass eine Annotation fehlerhaft ist. An dieser Stelle ist in der Datei ein JavaDoc-ähnlicher Kommentar. Was genau uns Google mit “WARNING – Parse error. type annotation incompatible with other annotations” sagen wollte, wissen wir allerdings auch nicht. Der betroffene Code sieht wie folgt aus:

/**
 * Create a cookie with the given name and value and other optional parameters.
 *
 * @example $.cookie('the_cookie', 'the_value');

Wenn wir weiterhin den Code offline vorkomprimieren (wie wir es uns für unsere REDAXO-AddOns vorgenommen haben), sollten wir vielleicht auf den Google Compiler wechseln. Allerdings belegt er mit knapp über 4 MB auch deutlich mehr Platz als der YUI Compressor (mit 800 KB) und kann kein CSS verarbeiten. Und damit fällt er dann doch wieder aus der Liste der Alternativen raus. Würden wir die Syntax-Änderungen des Packers nicht beachten, könnten wir auch ihn benutzen — immerhin gibt es einen .NET-Port, der sogar CSS komprimieren kann.

Es bleibt also alles beim alten, könnte man sagen. Aber gut, dass wir mal darüber gesprochen haben.

Nachtrag (Mo, 9.11.09): Der Google Compiler konvertiert alle in der Quelle enthaltenen Sonderzeichen / Umlaute in ihre Unicode-Schreibweise (ein ä wird zu \u00e4). Wir haben keine Möglichkeit gefunden, ihm das abzugewöhnen. Man kann also davon ausgehen, dass der Google Compiler bei Deutschen Dateien mit vielen Kommentaren schlechter abschneidet als die anderen Kandidaten.

5. November

World Usability Day 2009

von Wolf Brüning Kommentieren

Logo World Usability Day Software, die nicht das tut, was der Anwender will. Handys, deren Funktionen man nicht versteht. Automaten, die eher verwirren, als zum Ergebnis zu führen… kennen Sie das?
Keine Sorge, der November ist da! Und mit ihm steht am kommenden Donnerstag auch wieder der World Usabilty Day auf dem Kalender. Mittlerweile jährt sich dieser Aktionstag bereits zum fünften Mal und bietet diesmal mehr als 200 Veranstaltungen in über 40 Ländern zu den Themen User Interface Design, User Centered Design, User Experience Design und User und-so-weiter Design. In Deutschland wird in 18 Städten zu solchen Veranstaltungen eingeladen und neben Berlin, Hamburg, Stuttgart und München darf natürlich auch Magdeburg nicht fehlen.
Hauptsächlich von unseren Freunden von SCHROEDER+WENDT angetrieben, hat sich dieses Event seit 2005 auch in unserer schönen Stadt (einem “weißen Fleck inmitten der deutschen Usability-Landkarte” – Zitat Matthias Schroeder) etabliert. Wie man am untenstehenden Programm sehen kann, lohnt sich auf jeden Fall die Anwesenweit am 12.11. ab 16 Uhr im Forum Gestaltung (Brandenburger Str. 10, 39104 Magdeburg). Mit einem zweiten Blick in eben dieses Programm erkennt man desweiteren, dass wir diesmal nicht nur als passive Teilnehmer vor Ort sind, sondern uns aktiv mit einem Vortrag einbringen.

16:00 – Workshop „Webseiten mit Usability Methoden optimieren“

Mit praktischen Übungen und Tests werden Methoden zur Evaluation von Webseiten vermittelt. Schwerpunkt bildet hier zum einen die so genannte „heuristische Evaluation nach Nielsen“ die sich an Qualitätskriterien orientiert und zum anderen der Aufbau eines kleinen Usability-Tests. Die Teilnehmer erhalten somit einen Einblick in die Durchführung von Methoden zur Optimierung einer Webseite oder ähnlichen grafischen Oberflächen.

Voranmeldung bitte an mail@jana-hesselbarth.de
Jana Hesselbarth, Diplom-Designerin
arbeitet bei der Agentur SCHOLZ & VOLKMER (Wiesbaden) als Gestalterin im Webdesign, unter anderem für die Mercedes Benz Webseiten.
www.jana-hesselbarth.de

17:30 – Vortrag „Web Usability- Bewährte Verfahren, Fettnäpfchen & verbreitete Irrtümer“

Der Bereich der Usability umfasst eine Unmenge von Regeln, Best Practices und Hinweisen wie eine Webseite oder ein anderes User Interface zu gestalten ist. Einige dieser Regeln sind mittlerweile überholt oder stets Glaubenssätze gewesen, die stets weitergetragen aber nie wirklich überprüft worden sind. Der Vortrag beschäftigt sich mit diesen Mythen, der eigentlichen Wirklichkeit und den sich daraus ergebenden Konsequenzen. (Fokus des Vortrags ist Usability im Web und vergleichbaren bildschirmbasierten Nutzerinterfaces)

Wolf Brüning, Diplom-Computervisualist
Als Art Director der webvariants GbR (Magdeburg) trägt er die Verantwortung für alle kreativen und gestalterischen Aufgaben.
www.webvariants.de

18:00 – Pause

18:30 – Vortrag „Usability Strassentricks – Den inneren Dämon des Users verstehen“

„Usability Strassentricks – Den inneren Dämon des Users verstehen“
Besonders auf Verkaufswebseiten gilt: Usability, um mehr zu verkaufen. Durch einfache psychologische Prinzipien in der Planung werden hohe Conversion Raten schon von Beginn an erzielt und aufwendige Usability-Tests (fast) überflüssig. Dazu einige Beispiele, die in 5 Minuten umgesetzt werden können

Norman Janssen, Bachelor of Science Digitale Medien
ist Geschäftsführer der .mediacode. web solutions (Magdeburg), welche sich mit der Optimierung von Webseiten befasst.
www.mediacode.de

19:00 – Vortrag „Internet-Benutzung im Jahr 2019“

Das Internet wächst in alle unsere Lebensbereiche herein und wird immer weniger als solches wahrnehmbar. Vor 10 Jahren war Google gerade mal ein Jahr alt und mit dem Handy ins Internet gehen, war für die meisten eine völlig fremde Welt. Heute laufen fast alle Suchanfragen und Onlinewerbung über Google und über mein Handy kann ich sofort ein Luft- oder Straßenbild eines beliebigen Ortes auf der Erde erhalten. Wie wird diese, so wichtige Schnittstellen zwischen Mensch und Daten bzw. sogar zwischen Mensch und Welt, in wiederum 10 Jahren aussehen? Der Vortrag zeigt aktuelle Trends und Tendenzen und bietet einen Ausblick auf eine mögliche Zukunft.

Matthias C. Schroeder, Diplom-Designer
ist einer der Geschäftsführer der Agentur SCHROEDER + WENDT (Magdeburg), welche sich mit der benutzerfreundlichen Oberflächengestaltung von Webseiten und Software beschäftigt. Zudem ist er Vorstandsmitglied im Berufsverband für Usability, der German UPA.
www.schroeder-wendt.de

20:00 – Live-Expertenanalyse

Wo sollte und vor allem wie kann eine Webseite oder Software noch optimiert werden? In einer Live-Analyse zeigen Experten für Usability und visuelle Gestaltung der Agentur SCHROEDER + WENDT, die Optimierungsmöglichkeiten ihrer grafischen Oberfläche / Bedienung auf.
Bitte melden Sie ihre Beispiele vorab an unter: fragen@schroeder-wendt.de

Susi Augstin, Diplom-Designerin
Matthias C. Schroeder, Diplom-Designer
Reik Wendt, Diplom-Designer

Wir freuen uns auf jeden Fall auf neue und altbekannte Gesichter und selbstverständlich interessante Vorträge und Workshops. Also bis Donnerstag…

ZurückÄltere Blog-Beiträge