Ok jetzt zum Artikel. Vor ein einigen Tagen waren wir in Köln zum Symfony Day und Fabien hat in seiner Keynote ein wenig über Symfony2 philosophiert. Dabei hat er auch über MVC-Frameworks gesprochen und erklärt, dass man so gut wie nie in der Symfony-Doku finden wird, dass es sich dabei um eines handelt. Aber warum? Ist Symfony2 denn kein MVC-Framework? Wäre ja grausam, denn MVC verstehen wir und damit können wir auch arbeiten. Ja, Symfony ist auch weiterhin ein MVC-Framework, aber warum hat der Franzose das dann gesagt? Es ist ihm einfach egal.

Nutzt das Framework doch wie ihr wollt und wie es am besten zu euch passt. Ihr braucht MVC, dann kommt ihr eben so gut mit Symfony zurecht, wie jemand der einfach einen Webservice auf die Beine stellen will. Dank der Komponentisierung kann man auch viel kleinteiliger arbeiten und zum Beispiel nur den Class-Loader benutzen.

Hinter dem ganzen “I don’t care” stecken zwei Ideen. Zum einen will er die Verbreitung von Symfony fördern und dabei ist es sinnvoll bekannt zu machen, dass es eben viel mehr als ein MVC-Framework ist und man es überall einsetzen kann. Wiederverwendbarkeit ist einfach was feines. Und je mehr Projekte sf nutzen, umso schwieriger wird es an dem Thema vorbei zu kommen. Genial für eine Firma, die damit ihr Geld verdient. Zweiter Punkt ist eher so etwas prinzipielles. Wenn euch MVC nicht 100% zusagt, dann nutzt es nicht zu 100%. Erweitert die Ideen, programmiert nicht zu engstirnig. Wenn ihr ein MVCD machen wollt, dann macht es. Frische Ideen haben noch nie geschadet. Erfindet aber bitte das Rad an dieser Stelle nicht neu.

This talk was from Web Design Day (http://webdesignday.com) in beautiful Pittsburgh, PA.

This talk introduces the need to start thinking and acting in a more future-friendly (http://futurefriend.ly) way when approaching web design. The diversity of web-enabled devices is increasing at an alarming rate. We have to rethink our content and the contexts in which our content is viewed.

“Responsive Design bezeichnet eine Praxis im Webdesign, bei der der grafische Aufbau von Webseiten dynamisch und unter Berücksichtigung der Anforderungen des betrachtenden Gerätes erfolgt. Eine dafür wesentliche Voraussetzung sind Media Queries, also die Abfrage von Art und Eigenschaften des betrachtenden Gerätes. Eine Webseite wird somit auf einem großen Display anders dargestellt als auf einem Tablet-Computer/Tablet-PC oder Smartphone.”

Wir haben also Layout, die sich je nach Betrachter anpassen. Klingt ja fast so ein wenig wie die Heisenbergsche Unschärferelation. Wer zu dem Thema aber noch mehr wissen will, der sollte sich diese Links mal zu Gemühte führen:

• Boston Globe: Eine der ersten Zeitschriften, die den Schritt zum Repsonse Design gewagt haben und bei denen es auch gelungen ist. Schaut man sich die Seite zum Beispiel auf dem iPad an, so haben wir eine dreispaltige Seite wenn wir das Display Quer halten, bei Hochkant wird es zweispaltig.
• 50 Examples and Best Practices: Wer sich noch nicht so viel drunter vorstellen kann, kann hier 50 Beispiele sehen, wie es aussehen sollte. Sind echt schöne Sachen dabei und schon in der Zusammenfassung bekommt man ein gutes Gefühl darüber, wie das Prinzip funktioniert.
• Skeleton: Wenn man wirklich mal anfangen und eine Seite umsetzen will, kann man Skeleton, ein Boilerplate für Responsive Websites nutzen. Hatte selbst noch nicht die Zeit es zu testen und würde mich über Feedback freuen, aber sicherlich ist jede Open-Soruce-Lösung ein Gewinn.
• Grundlagen: Natürlich gibt es nicht nur englischsprachige Texte zu diesem Thema, nein die Kollegen von t3n haben sich auch die Mühe gemacht die Grundlagen zu erklären. Wichtig auch die weiterführenden Links am Ende, die auf weitere gute Seiten zeigen.
• Tutorial: Schönes englischsprachiges Tutorial (Danke an Alex für den Tipp).
• Alternativen: Wer sich nicht auf Responsive Webdesign festlegen will, der kann hier noch ein wenig über Alternativen lesen. Alles nur kurz angerissen, aber trotzdem erfährt man das nötigste, um dann selbst auf die Suche nach ausführlichen Artikel zu gehen.

So wie gesagt, heute eher die Verweise auf Fremdinhalte, aber da ich in dem Thema noch kein Experte bin, ist dass das beste was ich euch “antun” kann. Alles andere wäre sicherlich auch nicht sinnvoll.

• Fehlende Framework-Unterstützung: ESI klingt zwar einfach, aber wenn das Framework es nicht unterstützt, dann kann es haarig werden. Das System muss ja so gebaut sein, dass jeder Snippet der Seite unabhängig vom Rest gerendert werden kann. Soviel ich weiß, ist Symfony2 das erste und einzige Framework derzeit auf dem PHP-Markt das es unterstützt. Nachträglich sowas einzubauen halte ich für sehr komplex.
• Overhead: Das ist jetzt für jedes Projekt eine eigenen Rechenaufgabe. Nehmen wir an, wir nutzen ein relativ schwergewichtiges Framework, welches 100ms braucht um hochzufahren. Jetzt besteht unsere Seite im einfachsten Fall aus zwei Teilen. Da wir dank ESI beide getrennt haben, müssen wir jetzt zwei mal das Framework hochfahren. 200ms einfach im Framework verbraten ist halt schon mal ein doofer Startpunkt für eine Hochlastseite. Wir wollten ESI vor kurzem auch bei einer relativ bekannten Seite einführen und sind daran gescheitert, dass zwei Teile der Seite gar nicht cachebar waren und somit ESI keine Beschleunigung gebracht hätte.
• Parallelität: Wer gerade den Overhead-Punkt nicht einfach nur überflogen hat, der hat sich sicherlich die Frage gestellt, warum man die zwei ESI-Includes nicht einfach parallel abholt und somit immer nur das Maximum der beiden Requests zu buche schlägt. Tja, ESI kann das leider nur sequentiell. Wobei ich gerade nicht genau weiß, ob es eine ESI-Einschränkung oder ob die Varnisch-Implementierung das Problem ist. Wenn man es aber mal genau betrachtet, kann es schon ganz logisch sein. Was wäre, wenn ein Include Cookies setzt und das andere darauf zurückgreifen will? Wenn immer mal eins von beiden zuerst fertig ist, hat man kein konsistentes Verhalten und debugging wird die Hölle. Heisenbug lässt grüßen.

Das waren jetzt erstmal die von mir gesehenen drei Nachteile. Ihr werdet sicherlich auch noch einiges beitragen können.

Ach ja, heute geht meine Elternzeit zu Ende. Nach zwei Monaten zu hause wieder mal richtig arbeiten. Ich sag euch dann wie es war.

Es gibt so viele Facebookspiele und wenn mir noch mal jemand eine Farm Ville anfrage sendet, bekommt er den Popo versohlt. Warum geht man nicht einfach mal einen Schritt zurück und nutzt die Kommentarfunktion wie eine Kommandozeile?Damit könnte man so schöne Dinge umsetzen, wie zum Beispiel ein Textadventure. Ich glaube da hätte ich wirklich Spaß dran, wenn ich einfach überall so  ein Spiel spielen könnte. Speichern bräuchte ich auch nichts, denn überall finde ich die selben Kommentare. Quizspiele auf diese Art zu machen, wäre auch eine Bereicherung und da mal überall in den Hauptmeldungen auftauchen würde, wäre die Verbreitung sicherlich schnell recht gut.

Aus technischer Sicht könnte man da ein kleines PHP-Framework oder eine Komponente veröffentlichen, die sich um die Facebookanbindung kümmert. Vielleicht könnte man es so gestalten, dass es sich wirklich wie die Kommandozeile anfühlt. Müsste man mal ein wenig drüber nachdenken.

Betrachtet man das Caching-Verhalten einer Webseite, dann bemerkt man, dass sie so lange gültig sein kann, wie das aktuellste Element auf ihr. Existiert zum Beispiel eine Box mit den aktuellsten Nachrichten, die jede Minute aktualisiert werden muss,  so kann man mit reinem HTML da nichts machen. außer die komplette Seite maximal für eine Minute im Cache des Nutzers zu legen. Eigentlich eine nicht wirklich optimale Vorgehensweise, da die meisten Systeme zusätzlich so aufgebaut sind, dass sie immer die ganze Seite berechnen wenn eine Anfrage kommt. Gut einiges liegt im Cache, aber vieles eben auch nicht.

ESI kann dazu genutzt werden, dieses Problem ein wenig abzuschwächen und vielleicht sogar zu lösen. Eigentlich von Akamai vor einigen Jahren erfunden, wurde es 2001 als offizieller Standard bei der w3c eingereicht. Man braucht also keine Angst haben, dass man sich bei Verwendung auf eine Technologie festlegt, die keine Zukunft hat. Fangen wir aber an das Feature zu beleuchten, dass uns bei unserem Problem helfen kann.

Edge Side Includes bieten einem die Möglichkeit die Webseite in einzelne Bestandteile aufzuteilen und diese somit auch wie eigene HTML-Seiten zu betrachten. Nehmen wir an, der Header unserer Seite würde als ein solcher Bestandteil gekennzeichnet werden. Wir haben nun die Möglichkeit genau diesen Header einzeln zu Cachen und das schöne ist, wir nutzen die HTTP-Header, die wir eh schon kennen. Im ESI-Jargon sprechen wir einfach mal von includes und es würde wie folgt aussehen:

<esi:include src="http://phphatesme.com/header.php" />

Ziemlich einfach und verständlich, oder? ESI wird, wie man sieht, über XML-Elemente direkt im HTML gesteuert. Natürlich immer im ESI-Namespace, so wie es sich gehört. Jetzt kann man sich natürlich fragen, wer ein solches Tag versteht, die header.php anruft und die eigentliche Seite zusammenbaut. Varnish oder Squid wären hier zum Beispiel zwei Kandidaten.

Um diese Tags zu verarbeiten schaltet man eine Instanz vor den Webserver, der diese interpretieren kann. Einige HTTP-Acceleratoren können dies. Wir haben gute Erfahrungen mit Varnish gemacht. Egal welches Tool, es werden die einzelnen Bestandteile zusammengefügt und nach allen HTTP-Gesichtspunkten verarbeitet. Caching funktioniert also weiterhin wie gehabt. Nachdem alle Schnippsel abgeholt wurden, wird eine ganze Seite zusammengesetzt, die ESI-Tags rausgeworfen und ausgeliefert. Einfach, oder? Also zumindest das Prinzip und wenn man ein wenig mit einem HTTP-Accelerator rumgespielt hat, sollte einem hier kaum etwas spanisch vorkommen.

Da alle Tags entfernt werden ist diese Technologie für den Endkunden, also die Person, die am Browser sitzt komplett transparent. Es hat keine Ahnung rauszufinden, was da im Hintergrund passiert und trotzdem gewinnt man in den meisten Fällen sehr viel Performance auf den Servern, denn nicht mehr die ganze Seite, sondern nur einzelne Teile müssen berechnet werden.

Suchmaschinen bekommen übrigens auch ein vollständiges HTML-File, was ein großer Vorteil gegenüber AJAX ist, mit welchem man dieses System ja auch ohne Probleme hätte umsetzen können.

Falls Interesse besteht, würde ich noch Folgeartikel schreiben, denn etwas über Symfony2 und ESI hätte ich noch parat, wann ESI keinen Vorteil bringt, was ESI noch kann und wo Fallstricke lauern. Wären also vier an der Zahl, die ich wohl aufs restliche Jahr verteilen werde.