Facebook Fanpage Tricks Vol. 1
Strg+s, Alt+Tab, F5.
Kurz gefasst, ist das einer der eingeschleiften Arbeitsabläufe beim Erstellen von HTML- Templates. Erst recht, wenn nach dem groben Behau einer Website-Skulptur deren Makeup via CSS folgt, wird der ständige Wechsel zwischen Editor und Browser zum Mantra.
Befasst man sich mit der Thematik Customtabs auf Fanpages zu erstellen wird schnell offenbar, dass dieses Prinzip so nicht funktioniert bzw. um einiges umständlicher ist. Der von Facebook gelieferte Zugang, um eigenen Content mittels Quelltext zu hinterlegen, ist ein Formular im Browser mit einer Breite von 300 Pixeln. Das bedeutet, dass mit viel gutem Willen knapp 50 Zeichen nebeneinander passen. Dieser Wert kann schwanken, da innerhalb der Eingabemaske kein Monospace-Font verwendet wird. Wer also ansonsten Wert auf sauberen Codestyle legt kommt hier schnell an die Grenzen der Übersichtlichkeit, da Einrückungen und lange Attributsbezeichnungen die Zeile zum Umbrechen veranlassen.Allein diese Gesichtspunkte sind wohl Motivation genug, um sich einen Workflow anzueignen, der eine probate Alternative zum Coding innerhalb des FBML- Formulars darstellt.
So kommt an erster Stelle wieder der gute alte Editor ins Spiel. Mit vertrauten Eigenschaften wie Monospace- Font, Codehighlighting und einer Zeilenlänge über fast die komplette Bildschirmbreite lässt er für Programmierer ein familiäres Verbundenheitsgefühl aufkommen und ist Garant für systematischen (und somit übersichtlichen) Codestyle. An zweiter Stelle gilt es umzudenken. Um ein HTML- Template im Browser darstellen zu lassen, bedarf es einiger Tags, die beim Erstellen von Customtabs nicht zulässig sind. Die Lösung: ein Dummytemplate. Dieses besteht grundsätzlich aus einem Blockelement innerhalb der Bodytags, welches die essenziellen Styles enthält:
- eine Breite von 520 Pixeln
- overflow: hidden
Innerhalb dieses Elementes kann dann munter Quellcode hinterlegt werden, welcher die Inhalte beherbergt, die im Customtab der Fanpage erscheinen sollen. Ist alles auf einem Stand, der zufriedenstellend ist, gilt es lediglich diesen Quellcode zu kopieren und im FBML- Formular einzufügen. Nebenbei bemerkt ist es sinnvoll vor dem Einfügen ein paar Zeilenumbrüche im Formular zu setzen. Die Begründung: Die Darstellung des Formulars inklusive seines Inhaltes funktioniert nicht immer fehlerfrei. So kann es schon mal vorkommen, dass einem die letzte Zeile des Quelltextes nicht angezeigt wird und man annimmt einen Fehler gemacht zu haben, indem man ein Tag nicht geschlossen hat.
Aber HTML ohne CSS ist wie Currywurst ohne Pommes. Der saubere Weg ist demnach, Stylesheets in einer externen Datei zu definieren, auf welche innerhalb des HTML- Templates verwiesen wird. Grundsätzlich kein Problem bei der lokalen Entwicklung über den oben beschriebenen Weg. Im Handumdrehen ist eine Datei angelegt und mit Styledeklararionen befüllt. Einmal eingebunden, werden Änderungen an der Datei anstandslos übernommen und geben direkte Auskunft über das Können ihres Bearbeiters.
Arbeitet man an einer Fanpage, verhält sich die Sache etwas anders. Hat man das Template eines Customtabs inklusive zugehöriger Stylesheets entwickelt, kopiert man nun den Quelltext in das FBML- Formular und verweist auf die CSS- Datei. Nach unten scrollen, speichern, Customtab anklicken und das Ergebnis begutachten. Der beste Fall ist nun, dass alles so ist, wie man es sich wünscht. Hand auf´s Herz… das passiert eher selten. Eigentlich gibt es immer Dinge, die einem erst auffallen, nachdem man seinen Quellcode auf Facebook hinterlegt hat. Das ist der Punkt, an dem man sich selber zur Disziplin ermahnen muss.
Zu frühe Migration des Quellcodes bedeutet häufig, dass man nicht den als umständlich erscheinenden Weg geht, Änderungen am Dummytemplate im Editor vorzunehmen. Man neigt dazu, den Code gleich im Formular ändern zu wollen, immerhin repräsentiert es den kürzesten Weg zwischen Code und Darstellung und führt zu einem schnellen Ergebnis. Beim Anblick des Quelltextes im Formular wird allerdings das eingangs angesprochene Problem wieder offenbar: Der Code ist wüst über Zeilenumbrüche verteilt und die Codestelle zu finden, die es zu ändern gilt, avanciert zur höheren Aufgabe. Eine versehentlich falsche Änderung ist nicht mehr wie im Editor über die vertraute Tastenkombination Strg + z zu revidieren. Hinzu kommt, dass man nun nicht mehr nur eine änderungswürdige Stelle im Code hat, die es zu finden gilt.
In diesem Zusammenhang bedarf es auch eines Umdenkens, was die Deklaration von Stylesheets angeht. Auch bei größter Anstrengung bezüglich der Selbstdisziplin macht es Facebook einem hier nicht so einfach. Spätestens ab dem Moment, in dem man feststellt, dass jede Änderung an der CSS- Datei bezüglich ihrer Wirkung auf die Fanpage effektfrei bleibt, sollte man der Ursache auf den Grund gehen.
Die Erklärung des Phänomens ist einfach. Um den Quelltext in die Plattform einzubinden, durchläuft dieser ein Preparsing. Damit wird gewährleistet, dass Quellcode, der nicht den Vorgaben entspricht (beispielsweise unzulässige Tags enthält), stillschweigend gelöscht wird bevor der Browser beginnt, den Code zu parsen. Genau das geschieht auch mit extern definierten Stylesheets. Diese werden allerdings nicht bei jedem Aufruf des Customtabs neu geparst. Einmal auf eine CSS- Datei verwiesen, wird diese verarbeitet und serverseitig gespeichert. Der Effekt: Ändert man die Datei im Nachhinein, können die Änderungen nicht übernommen werden da lediglich am Dateinamen im Einbindungspfad detektiert werden kann, ob diese Datei schon einmal eingelesen wurde. Ändert man also eine CSS- Datei ohne ihren Namen zu ändern und diesen korrekt im Quelltext einzubinden, besteht kein Anlass die Datei erneut zu parsen.
Ändert man mit jeder Änderung der CSS- Datei also ihren Namen, funktioniert alles zufriedenstellend. Das kostet freilich ein bisschen mehr Zeit und Mühe. Im Gegensatz zum Zeit- und Nervenaufwand, der einen ansonsten erwartet ist das aber sicher zu verschmerzen.
