So, ich habe hier schon mal die Präsentation meines Vortrages über "OOP in Drupal". Das dazugehörige Podcast folt noch (in Bild und Ton)… 1.6 GB ist leider auch für YouTube und wohl auch für die Leitung hier zu viel, also muss ich bis zuhause warten.
Der 1. Tag des Drupalmediacamps sind bereits Geschichte und der zweite Tag hat bereits angefangen. Wenn ich auf den vergangenen Tag zurückblicke, dann weiss ich nicht so recht, was ich schreiben soll. Vom Technischen her, wurde relativ wenig geboten. Es gab rel. viele Session, welche lediglich Projekte beschrieben (was wohl auch das Ziel des ersten Tages war).
Es war jedoch äusserst interessant, die verschiedenen Leute zu treffen und mit ihnen zu sprechen und es kamen noch einige interessante Ideen und Inputs zusammen. Das Publikum war auch relativ breit gefächert: Vom Teenager bis zur Grossmutter waren eigentlich alle vorhanden.
Oky, morgen ist es soweit. Ich muss noch die letzten Folien für meine kleine Präsentation machen. Weiss schon jemand, ob er teilnehmen wird? Würde mich interessieren, was so die Hintergrundkenntnisse sind und was die Erwartungen sind. Oder kommt vielleicht gar niemand an meine Session? …? Hoffen wir es mal nicht.
Die Drupal Architektur in Kürze
Ich muss an dieser Stelle sagen, dass ich auch nicht in-depth Kenntnisse der genauen Vorgehensweise habe, ich bin kein Drupal Core Entwickler. Die Grundlegenden Prinzipien sollten dennoch klar sein. Hier sind eigentlich zwei wichtige Grundlagen:
Front-Controller
Diese Architektur ist eigentlich für PHP Anwendungen sehr beliebt und läuft nach einem relativ einfachen Muster ab: Jeder Seitenaufruf erfolgt IMMER über index.php (die Ur-index.php Datei!). Dort werden dann zuerst in abhängigkeit der URL die ganzen nötigen Datein geladen (-> was als Bootstrap benannt wird), worauf wieder eine Seite ausgegeben wird. Es ist also nicht so, dass die URL die Ordnerhierarchie abbildet, wie das der Fall wäre, wenn man eine statische HTML Seite baut!
Das Hook System
Dieses System macht Drupal so flexibel. Was ist ein Hook? Ein Haken. Na und? Die Analogie dazu ist, dass man sich über diese Haken (oder eben Hooks) ins System einklinken kann. Der Ablauf hier sieht ungefähr wie folgt aus: Das Menu Modul wird geladen. Im ersten Schritt werden hier die wichtigsten Dinge geladen. In einem zweiten Schritt werden alle Module eingesammelt, welche den Hook Menu (hook_menu) implementieren. Damit dieser auch gefunden wird, gibt der jeweilige Hook eine Namenskonvention vor, um hook_menu zu implementieren müsste ich also in Modul xyz schreiben: function xyz_menu(). Es wird also die Funktion xyz_menu, cck_menu, imagecache_menu, fast_gallery_menu usw. aufgerufen. Danach kommt der nächste Hook dran, z.B. hook_nodeapi, welcher wieder schaut, welches Modul diesen Hook implementiert, um die entsprechende Funktion aufzurufen.
So kann man ein Modul schreiben, welches sich ohne Probleme in das bestehende System integrieren lässt und es auch ohne Probleme wieder entfernen. Es lassen sich im Modul auch eigene Hooks definieren (Views macht das zum Beispiel). So können andere Module Einfluss auf die Logik nehmen. Es wird also eigentlich sehr schnell klar, dass das System dadurch sehr flexibel wird.
Die Hooks und die dazugehörige Dokumentation sind unter api.drupal.org auffindbar.
Theming und Hooks
Das Theming verfolgt eigentlich ein ähnliches System. Es gibt z.B. die Funktion theme_image($image). Diese wird aber wie folgt aufgerufen: theme('image',$image). Warum so kompliziert?? Ganz einfach, diese Theme Funktion ist ähnlich wie das Hook System und kann überschrieben werden, z.B. in der template.php Datei. Wenn diese Funktion aufgerufen wird, wird gleich wie bei den Hooks nach passenden Funktionen geschaut, wird nichts gefunden, dann wird die default Funktion (eben theme_image(…)) verwendet, ansonsten die neue Funktion. Dadurch lässt sich z.B. der Output für ein Bild verändern, ohne dadurch die eigentlich theme_image Funktion verändern zu müssen.
Vorwort
Irgendwie hat sich dieser Artikel in die Unendlichkeit verlängert, daher werde ich einen Zwei- oder Dreiteiler daraus machen. In diesem ersten Teil geht es lediglich um die Konzepte der Objektorientierten Programmierung und kann eigentlich getrost übersprungen werden, falls man damit bereits vertraut ist. Für alle anderen Empfehle ich doch schwer, sich diesen Artikel mal genüsslich zu lesen (und wahrscheinlich mal eine einfache Hello World Klasse zu schreiben und wohl via Google noch ein wenig mehr darüber zu lesen.
Wahrscheinlich hat schon jeder mal etwas von Objekten und Klassen gehört. Seit Java gross geworden ist, gehört es zu einer guten Software, dass sie eine Objekte Orientierte Architektur aufweist. Dieses Post soll in einigen Zeilen die Konzepte der Objekte Orientierten Programmierung (OOP) vermitteln und dann aufzeigen, wie diese für die Entwicklung von Drupal Modulen eingesetzt werden kann.
Was ist ein Objekt?
Das Konzept von Klassen und Objekten ist für den Anfänger nicht ganz so einfach zu verstehen. Ist der Groschen dann jedoch einmal gefallen, dann kann man es sich nicht mehr vorstellen, dass man es einmal nicht verstanden hat (wohl ähnlich wie beim Autofahren). Ich werde mal versuchen, es in meinen Worten zu erklären. Falls diese nicht verständlich sind, dann gibt es sehr viele Bücher, die versuchen es zu erklären. Google ist dein Freund.
Es gibt Klassen und es gibt Objekte. Klassen sind nicht gleich Objekten! Dies mal als Grundlage. Eine Klasse kann als Bauplan verstanden werden. Diese Klasse gibt vor, wie ein Objekt gebaut werden muss. Nehmen wir an, wir hätten eine Klasse "Auto". Diese Klasse kann nichts machen, sprich das Auto kann nicht fahren, denn es ist lediglich ein Bauplan für ein Auto. Die Klasse "Auto" schreibt jedoch folgende Dinge vor: Ein Auto hat: 4 Räder, es kann vorwärts und Rückwärts fahren und es ist grün. (ein sehr triviales Auto). Der Plan (die Klasse für dieses Auto würde in PHP wie folgt aussehen:
<!–?php
Class Auto{
private wheels = 4;
private color = "green";
public function driveForward(){
//Hier Code, damit Auto vorwärts fährt.
}
public function driveBackward(){
//hier Code, damit Auto rückwärts fährt.
}
}
?>
Es gibt Variablen und es gibt Methoden (oder auch Funktionen). Die Variablen beschreiben Eigenschaften des Autos, während die Methoden die Funktionen des Autos beschreiben. Das ist jetzt der Plan. Wie gesagt, der Plan alleine kann noch nicht machen, dass dieses Auto fährt. Es ist lediglich der Bauplan für das Objekt!!!
Jetzt wollen wir das Auto zum Fahren bringen. Dazu müssen wir es jedoch zuerst bauen:
<!–?php
$auto = new Auto();
?>
So, jetzt ist das Auto erstellt. Wir können jetzt dem Auto sagen, dass es vorwärts fahren soll:
<!–?php
$auto->driveForward();
?>
Oky, damit ist hoffentlich ungefähr, was eine Klasse ist und was ein Objekt ist. Nochmals: Eine Klasse ist der Bauplan für das Objekt. Ein Objekt ist als eine sog. Instanz einer Klasse. Es gibt 1 Klasse für unser Auto, aber ich kann dann unendlich viele Instanzen davon erzeugen, sprich z.B. 100 Autos (Objekte).
Unser Beispiel mit dem Auto macht jedoch eigentlich erst Sinn, wenn mehrere verschiedene Objekte beteiligt sind: z.B. Das Objekt "Auto" hat ein Objekt "Motor", 4 Objekte "Räder", 4 Objekte "Tür" usw. Wie man sieht, lässt sich damit die Welt abbilden, oder eben Modellieren. Denn die Objekte können miteinander interagieren. Sprich, das Auto könnte auf dem Motor die Methode starten() aufrufen usw.
Objekte und Klasse in Software
Es stellt sich jetzt natürlich die Frage, warum man das ganze in Software braucht. Eine grosse Liste von Funktionen wäre doch viel einfacher. Wenn man ein wenig die Geschichte anschaut, wird das jedoch sehr schnell klar. Eine Programmiersprache, war mal Basic. Dort steht das ganze Programm in einer Datei (meines Wissens), was dann irgendwie so ausschaut (ich verwende PHP Syntax, welcher aber weder PHP noch Basic ist, aber er illustriert die Punkte, welche ich machen soll):
1 print 'hello world'; 2 print 'enter your name'; 3 $name = $_GET['name']; 4 if($name == 'rapsli'){ goto(10) } else{ goto(12) } 10 print 'ich bin cool' 11 goto(20) 12 print 'ich bin uncool' 13 goto(20) 20 print 'danke und tschüss'
Es ist glaube ich jedem leicht verstänlich, dass man so keine wirklichen Programme schreiben kann, denn der Code läuft von oben nach unten durch. Goto erlaubt zwar so Pseudeaufrufe, aber das macht das ganze nicht wirklich besser. Noch kritischer wird das ganze, wenn mehrere Leute daran arbeiten. Wie soll man das denn noch unterteilen?? Eine Katastrophe!
Sehr populär ist der Funktionale Ansatz, welcher daraus entstanden ist und ein wenig verwandt mit dem Goto ist:
function getName(){ print 'hello world'; print 'enter your name'; $name = $_GET['name']; return $name; } function printOpinion($op){ print $op; } if(getName() == 'rapsli'){ printOpinion('ich bin cool'); } else{ printOpinion('ich bin uncool'); } printOpinion('danke und tschüss');
Es werden Funktionen definiert, welche dann verwendet werden können im Eigentlichen Programm. Dadurch werden eigentlich zwei Dinge erreicht: 1. Falls die gleiche Aufgabe mehrere Male durchgeführt werden muss, dann muss nicht der Code dubliziert werden, sondern man kann einfach die Funktion mehrere Male aufrufen. 2. Wenn mehrere Personen am gleichen Progamm arbeiten, dann kann das ganze gekapselt werden. Programmierer A ist für Funktion 1 zuständig, während Programmierer B für Funktion 2 zuständig ist. Man muss sich lediglich darauf einigen, was die Funktion für Argumente übernimmt und was sie zurück gibt. Dies ist doch eigentlich schon ein sehr grosser Schritt, aber eben meistens für richtig Grosse Projekte noch nicht gut.
Vorteile von OOP
OOP hat einige sehr wesentliche Vorteile:
Das sind doch schon einige gewichtige Vorteile, welche eigentlich in der heutigen Software Welt nicht mehr wegzudenken sind. Eigentlich setzen auch alle neuen Programmiersprachen darauf:
Dann gibt es noch SmallTalk, Eiffel und wie sie alle heissen… Was ich damit sagen will, die Zukunft liegt auf jeden Fall bei Objekten und Klassen, Vererbung und Polymorphismus.
Als Angesteller von Previon, werde ich am Drupal Media Camp auch eine kleine Session abhalten. Das Thema: Drupal und OOP. Ich habe dazu bereits einen Blogpost geschrieben und werde die dort beschriebenen Konzepte in der Session vorstellen…
Falls jemand Inputs/Bemerkungen/Verbesserungen dazu hat… bitte das Kommentarfeld dazu verwenden. Ich wäre natürlich sehr froh darüber, denn ich bin schon ein wenig nervös.
Es kommen immer wieder neue Administrationstools, dashboard usw. hinzu, aber ich denke, ich bleibe dem Admin Menu treu. Das Admin Menu gibt das Admin Menu als Dropdown Menu aus. Es beschränkt sich dabei auf einen Balken von 20 Pixel am oberen Ende des Bildschirms. Und erlaubt den Zugriff auf sämliche für die Administration notwendigen Seiten.
Admin Menu hat jedoch noch ein paar andere nette Features: Es wird angezeigt, wieviele Besucher aktuell auf der Seite sind. Zusätzlich befinden sich in der linken oberen Ecke ein Schnellzugriff auf diverse wichtige Admin Tasks: Cache leeren, Cronjob aufführen und updates.php Seite aufrufen. Cache leeren und auch den Variablen Editor aufrufen wird erst mit dem Devel Modul über Admin Menu möglich.
Einsatz:
Dieses Modul ist einfach ein Must für jeden Administrator einer Drupalseite, weil dadurch viele der täglichen Tasks eines Drupal Admins viel schneller durchgeführt werden können.
Ich bin immer wieder überrascht, wieviele Module es gibt, welche man eigentlich gar nicht richtig kennt, bzw. man weiss nicht richtig, wie diese einzusetzen sind. Daher möchte ich hier eine kleine neue Serie starten, in der ich ein paar meiner Lieblingsmodule nehme und kurz erkläre, was sie machen und wie man sie am besten verwendet. Selbstverständlich kannst du mir auch eine Anfrage für ein bestimmtes Modul schicken. Ich kann zwar nicht versprechen, dass ich auch darauf eingehen werde, aber Inputs sind immer gut, und so lerne ich vielleicht auch mal ein paar neue Module kennen.
Ich bräuchte noch irgend einen guten Namen für diese Serie. Wie wäre: "Drupal Module – Review und Tutorial".
Masquerade
Ein kleines praktisches Helferlein, welches besonders dann sehr hilfreich ist, wenn eine Seite mit mereren Benutzern und Rollen gebaut wird. Es erlaubt dem Administrator (oder wer auch immer die entsprechende Berechtigung hat) in die Rolle einer beliebigen anderen Person zu schlüpfen. Dadurch kann man relativ einfach testen, ob die Rollen richtig gesetzt sind, ohne für jede Rolle einen eigenen Testuser anzulegen, und sich dann dauernd auszuloggen und wieder einzuloggen. Dies kann ein echtes Zeitersparnis sein und sollte eigentlich auf keiner Multiuser Seite fehlen, denn sonst passiert es sehr schnell, dass man die Berechtigungen falsch eingestellt hat, weil man nicht getestet hat.
Installieren und Konfigurieren:
Installation erfolgt wie jedes andere Drupal Modul. Einfach das Masquerade Modul installieren. Danach muss man in die Block Verwaltung gehen und dort den Masquerade Block hinzufügen, sonst kann man nämlich gar nichts damit anfangen. Sobald der Block hinzugefügt ist, erscheint ein kleines Formular mit Autocompletion -> man kann sich jetzt als einen beliebigen User tarnen. Oh, nicht vergessen, noch die richtigen Berechtigungen bei den Rollen zu setzten, sonst passiert nämlich gar nichts.
Unter admin/settings/masquerade lassen sich noch ein paar Einstellungen vornehmen. Besonders die Quickswitches sind sehr sehr nützlich.
Warnung:
Die Berechtigungen für die Benutzung von Masquerade nicht falsch setzen, das könnte sonst fatale folgen haben. Wenn nämlich der normale Besucher die Berechtigung für die Benutzung von Masquerade hat, so kann er sich als einen beliebigen User "tarnen" -> auch als Admin!!!
Für alle die, die es noch nicht gesehen haben. Auf der linken Seite gibt es einen neuen Block: "Nützliches rund um Drupal". Ich bin eigentlic ein fleissiger Leser von Planet Drupal und sehe da immer wieder Beitrage, Module oder Themes, welche ich cool finde, aber vielleicht nicht gerade die Zeit habe, mir das genauer anzuschauen. Daher habe ich ein kleines delicious RSS Feed eingerichtet, damit ich die interessanten Beiträge später nicht vergesse.
Vielleicht nützt es ja dem einen oder anderen etwas…
Yes. Vor ziemlich genau 6 Monaten habe ich mit diesem Projekt angefangen. Es ging darum, zusammen mit einem Reisebüro einen Prototypen für eine Co-Browsing Applikation zu entwickeln und diesen zu evaluieren. Hier ein kurzer Überblick:
Resultat ist ein sehr interessantes System, welches in Drupal geschrieben ist. Das System verfolgt das Ziel, die Reiseberatung per Telefon visuell zu unterstützen. Dazu dient eben dieses Co-Browsing System. Ein Co-Browsing System erlaubt mehreren Benutzer synchronisiert zu browsen.
Dadurch gewinnt die Telefonberatung wieder an Bedeutung, denn:
Das Szenario sieht wie folgt aus: Der Benutzer suft auf der Seite, er kann sich die ganzen Produkte zusammenklicken und dann auf Wunsch eine Beratungsanfrage abschicken. Sobald ein Berater frei ist, bekomme der Kunde einen Rückruf. Der Berater kann sich jetzt beim Kunden einklinken und sich seinen "Warenkorb" anschauen und gegebenfalls weitere Ratschläge geben.
Oky, für die Arbeit wurde das Szenario ein wenig vereinfacht, aber das Grundprinzip des Co-Browsen bleibt bestehen.
Technisch gesehen wurde es als eine Push-/Poll Architektur implementiert. Diese weist natürlich einige Mängel auf, aber war für die Zwecke vollkommend ausreichend.
Warum habe ich Drupal gewählt? Ganz einfach, ich liebe Drupal ;). Nein, im Ernst:
Es sind nicht viele Gründe, aber die haben eigentlich gereicht. Zudem ermöglich die Modularisierung eine gute Abkapslung -> was wiederum einfacherer Code bedeutet.
Oky. Jetzt ist es Zeit zum Schlafen. Falls jemand an der Arbeit interessiert ist, kann er sich gerne bei mir melden. Wie gesagt: Drupal steht in der Arbeit nicht im Vordergrund, sondern war lediglich Mittel zum Zweck, aber es stecken doch ein paar interessate Konzepte hinter dem Businesscase.