Oskar Welzl: Weblog zur Homepage

Anders als bei blogr oder Weblife hat knallgrau hier bei twoday ja (noch?) keinen Tagging-Mechanismus eingebaut. (Klingt komisch, ist aber so. *g*) Einen seither immer wieder verwendeten Workaround hat Daniel schon im Jänner 2006 präsentiert: Ein Script fordert zur Tag-Eingabe auf und produziert HTML-Code, aus dem Technorati dann Tags extrahieren kann. Der HTML-Code landet direkt im Textbereich des Beitrags. Nachteil dabei: Die Tags sind nicht „wiederverwertbar“ (z.B. für del.icio.us oder im RSS-Feed). Außerdem wirken sich zu große Änderungen bei den Tags auf den Zeitstempel „modifytime“ aus, was unerwünschte Nebeneffekte hat.

Wie also tun?

Ähnlich wie beim Geotagging können zusätzliche Eingabefelder im Formular für das Erstellen/Ändern von Einträgen (Story.editForm) weiterhelfen, das man über „Layout verwalten > Skins“ erreicht:

<p>
<% message key="Story.create.title"%>:<br />
<% story.content part="title" as="editor" size="24" class="formTitle" %>
</p>
<p>
<% message key="Story.create.text"%>:<br />
<% story.content part="text" as="editor" cols="60" rows="15" class="formText" %>
<br />
Tag 1: <% story.content part="tag.1" as="editor" size="30" %> <br/>
Tag 2: <% story.content part="tag.2" as="editor" size="30" %> <br/>
</p>

Die fett hervorgehobenen Stellen sind die neuen Eingabefelder für Tags. Auch diese Lösung hat einen Nachteil: Man muß sich bei der Änderung von „Story.editForm“ auf eine maximale Anzahl von Tags festlegen und für jedes Tag ein eigenes Eingabefeld bauen. Hier im Beispiel sind es zwei („tag.1“ und „tag.2“), ich habe mich in meinem Blog für neun entschieden. Zu viele sind in der Darstellung/Weiterverarbeitung extrem umständlich zu handhaben, zu wenige machen einfach keinen Spaß.

Eingesetzt wird das Tag in Skins wie z.B. story.Display. Dabei kann es auf zwei verschiedene Arten aufgerufen werden. <% story.content part="tag.1" as="plaintext" encoding="xml" %> stellt das Tag so dar, wie es eingegeben wurde - mit Umlauten, Leerzeichen, Schrägstrichen und allem, was drin ist. Das ist der Text, wie man ihn lesen soll. Die zweite Variante, <% story.content part="tag.1" as="plaintext" encoding="url" %>, codiert „gefährliche“ Sonderzeichen, die in URIs nicht vorkommen sollen, annähernd nach RFC 3986 um (z.B. „%C3%96sterreich“ statt „Österreich“). Leerzeichen in Wortgruppen werden aber durch ein „+“ ersetzt, was zwar nicht RFC 3986 entspricht, praktischerweise aber genau das ist, was fast alle relevanten Webservices in URLs erwarten.

Die folgende Konstruktion nutzt beide Varianten:

<% story.content part="tag.1" prefix='Tag: <a href="http://technorati.com/tag/' suffix='" rel="tag">' as="plaintext" encoding="url" %><% story.content part="tag.1" suffix='</a>' as="plaintext" encoding="xml" %>

Wenn tag.1 z.B. mit „Österreich“ befüllt wurde, erzeugt sie den HTML-Code Tag: <a href="http://technorati.com/tag/%C3%96sterreich" rel="tag">Österreich</a>. Das ist schon mal sehr praktisch und flexibel: einfach statt der Technorati-URL irgend ein anderes Fragment nehmen, und auch dorthin wird verlinkt.

Die Tags sollten dann auch im RSS-Feed landen, und zwar sinnvollerweise als „dc:subject“. Dort werden sie von Webservices wie Technorati erwartet, außerdem entspricht das der Definition für dieses Feld, die lautet:

The topic of the resource. (Comment: Typically, the topic will be represented using keywords, key phrases, or classification codes.)

Es zahlt sich jedenfalls aus, die Änderung im RSS-Feed vorzunehmen (die relevanten Skins sind Story.rssItem und Story.rssItemSummary). In der Standardeinstellung schreibt twoday dort nämlich einen vollen HTML-Link (also mit <a href="…">) auf die Übersichtsseite des Beitrags-Themas in das Feld dc:subject, was ein bißchen über die oben zitierte Definition des Feldes hinaus schießt und Technorati beim Versuch, Tags automatisch zu extrahieren, völlig durcheinander bringt.

Wenn man schon mal bei den RSS-Feeds ist und einen ausgeprägten Fetisch für Standards eintwickelt hat, die niemanden interessieren, sollte man noch eine Änderung vornehmen. Der Codeabschnitt

<% story.content part="text" prefix="<description>" suffix="</description>" encode="xml" %> 

ist durch den nachfolgenden zu ersetzen:

<% story.content part="text" prefix="<description>" suffix="</description>" encode="xml" as="plaintext" %> 

Mit dieser Ergänzung („as="plaintext"“) schneidet twoday das HTML-Markup aus dem Beitragstext und schreibt ihn ohne Links, Bilder und Formatierungen in den Feed. Ja, tatsächlich, das müßte so sein, auch wenns keiner macht. HTML-Markup gehört in das Feld „<content:encoded>“ aus dem Modul Content, das man auch noch einfügen kann, wenn man mag. (Namespace nicht vergessen!)

Tja, so funktioniert dann auch Tagging mit twoday, solange man sich eine vernünftige Anzahl von Eingabefeldern überlegt. Eines stört mich noch an dieser Lösung: Die Beschreibung der Ausgabe für mehrere Tag-Felder in den einzelnen Skins ist extrem schwerfällig. Ich habe keine Möglichkeit gefunden, alle Tags als Gesamtheit (z.B. als Liste) anzusprechen. Bei neun Tags, die immer alle gleich behandelt werden sollen, wird das trotz Copy&Paste schnell unflexibel, unübersichtlich und lästig. Hoffentlich muß ich keine großen Änderungen mehr an der Darstellung vornehmen, für die tägliche Eingabe beim Bloggen paßts ja.