RunRails-Blog

Ich habe die letzten Tage viel Zeit mit einem AJAX-Chat für die Spekunauten verbracht. Dort habe ich mich von .RJS-Templates verabschiedet und erzeuge den meisten View-Code direkt im Controller mit render_to_string.

Für Javascript-Funktionen benötigte ich aber auch oft javascript_escape (bei der Parameterübergabe) und andere Helper, die nur im View zur Verfügung stehen.

Es gibt verschiedene Lösungen, dass zu erreichen. Die unkomplizierteste die ich gefunden habe lautet @template.

Mit @template (ich habe dieses Feature aus einem Kommentar von 2005 gefunden, es scheint also noch aus 1.x-Tagen zu sein) kann man alle Funktionen innerhalb des Views aufrufen, also z.B. @template.escape_javascript!

Ende Oktober bin ich auf meinem ersten Barcamp! Habe es geschafft mich dort heute Mittag in allen Veranstaltungen einzutragen, obwohl der Server total überlastet war.

Als Barcamp-Neuling ist man ja angehalten, etwas dazu beizutragen. Ich habe mir überlegt einen Vortrag über Facebook-Anwendungen mit Ruby on Rails zu halten. Ich glaube das Thema ist gerade in Deutschland recht interessant, wo Facebook ja noch nicht so lange expandiert. Neben einem sehr empfehlenswerten Buch, welches ich dazu gelesen habe, (momentan nur als PDF erhältlich) ist seit einigen Tagen auch meine erste Facebook-Anwendung online.

Da bis zum Barcamp-Termin noch ein bisschen Zeit verstreicht, kann ich vielleicht auch berichten, was für Marketing-Erfolge man sich in Deutschland davon versprechen kann. Facebook liegt zwar bei den Nutzerzahlen stark hinter StudiVZ, wer-kennt-wen und anderen Netzwerken, nur was ist die Alternative? Keine der anderen Plattformen* biete eine API für eigene Anwendungen an.

____

* Anfang des Jahres hat StudiVZ eine eigene API angekündigt. Bisher gab es zu dem Thema aber noch keine Neuigkeiten.

Angenommen man hat schon eine Menge Seiten im Google-Index. Nun möchte man das Schema der URLs dieser Seiten verändern um es beispielsweise ein bisschen SEO zu betreiben.

Die naheliegendste Vorgehensweise dabei wäre, eine neue Action im Controller zu schreiben und von dort aus auf die neue URL umzuleiten:


def some_action_old
redirect_to some_action_url(params[:id])
end

Oder so ähnlich. Für den Besucher sieht das prima aus, denn er sieht nur die neue URL im Browser. Googlebot bekommt beim nächsten Crawl ebenfalls die Weiterleitung mitgeteilt, man könnte daher annehmen er würde ab dann die neue URL speichern. Das wird aber nicht passieren, warum?

redirect_to liefert den Status-Code 302 (Moved temporarily) zurück. Wie der Name schon sagt, gilt diese Umleitung nur vorübergehenderweise- nur für diesen speziellen Seitenaufruf. Im normalen Gebrauch macht das auch Sinn: Angenommen man klickt auf einen Logout-Link, so wird man anschließend zur Startseite umgeleitet. Das bedeutet jedoch nicht, dass ab jetzt die URL der Startseite die gleiche Bedeutung wie die Logout-URL hat.

Für diesen Fall gibt es den Status-Code 301 (Moved permanently). Um diesen zurückzugeben, muss man direkt in den Header zugreifen. (Ich fand diesen Trick über Snippets.dzone.com).


def some_action_old
redirect_to post_url(@post), :status=>301
end

Jetzt wird der Googlebot nach und nach die alten URLs gegen die neuen austauschen. Software zum auswerten der Serverlogs (ich verwende AWStats) zeigt eine Tabelle mit den häufigsten HTTP-Statuscodes an. Dort kann man durch die Zahl der 301-Redirects abschätzen, wie oft dieser Aufruf tatsächlich genutzt wurde.