Action Controller
In Rails MVC-Architektur dienen die abgeleiteten Klassen des ApplicationControllers als Verknüpfung
zwischen den Daten und der Ausgabe. Um die Funktionalität in einer Anwendung zu implementieren muss
zuerst ein neuer Controller erzeugt werden:
> ruby script\generate controller Newslist show_list show_by_date
Dieser so neu erzeugte Action Controller enthält nun die drei angegebenen Methoden:
app\controllers\newslist_controller.rb
Wird nun z.B. http://www.foo.bar/show_list als URL aufgerufen, so wird die Methode show_list ausgeführt.
Jede der Methoden eines Controllers ist standardmäßig public und somit von Außen aufrufbar.
Dienen Methoden nur der intern Redundanzverhinderung, sollen diese nicht direkt aufgerufen werden
können. Durch die Verwendung von protected, private oder hide_action() wird dieses erreicht, z.B.
Controllerkonventionen
URL: http://.../blog/list
Klasse: BlogController
Pfad: app/controller/blog_controller.rb
Methode: show()
Layout: app/views/layouts/blog.rhtml
[top]
Controllerumgebung
Ein Controller stellt eine Reihe von Umgebungsvariablen für seine Methoden bereit,
die wichtigsten sind:
request
Diese Variable enthält alle Informationen die Rails über die aktuelle Anfrage vorliegt.
Hierzu gehören die IP des Benutzers (request.remote_ip), der Browsertyp der anfragt
und die Art der Anfrage (z.B. :post, oder :get)
params
Params enthält die Variablen des Searchpath der URL in Form eines Hashes.
cookies
Enthält die zur Anfrage passenden Cookies. Wird dieser Variablen ein Wert zugewiesen, so wird ein
neuer Cookie beim Benutzer erzeugt.
sessions
Enthält alle Daten, die in der momentanen Session gesetzt wurden.
[top]
Render
Render(), dieser unscheinbare Befehl stellt das Herz der Outputgenerierung in Rails da.
Um seine Funktionalität entfalten zu können benötigt er einen Hash als Parameter, welcher alle
notwendigen Informationen enthält. Dieser Hash baut sich wie folgt zusammen:
render (:nothing => true)
Dies stellt die einfachste Verwendung von „render" da, ein leeres Dokument wird zum Useragent gesendet.
render (:text => String)
Dies stellt eine weitere einfache Operation der Funktion da. Sie sendet den übergebenen String, so wie er angegeben ist,
an den Useragent.
render (:inline => String)
Der Inline-Hash veranlasst „render", den übergebenen String als Template (vgl. Views) zu senden.
render (:action => action_name)
Dieser Parameter veranlasst „render" eine Ausgabe einer anderen Methode des Controllers auszuliefern. (!Meist
wird es fälschlicher Weise, anstatt des eigentlich gewollten redirect_to verwendet!)
render (:template => name) / render (:partial => name) / render (:file => path/tempalte)
Hier wird das jeweils angegebene Template (vgl. Views) ausgewertet und gezeichnet.
Beispiele:
Der letzte Aufruf ist der kürzest Mögliche, jedoch nicht der Unmächtigste:
Zunächst wird der Controller und die aktuelle Methode ermittelt, somit ist das gewünschte Template
bekannt und kann gerendert werden. Dieser Vorgang wird von Rails implizit bei jedem Methodenaufruf
durchgeführt, sofern die render-Funktion nicht manuell aufgerufen wird.
[top]
Methodendelegierung
In Webanwendungen kommt es häufig vor, dass eine Anfrage von einer Funktion bearbeitet wird, jedoch eine
andere Funktion den Output generiert. Normalerweise wird diese Output-Funktion am Ende der
Verarbeitung ausgeführt, z.B. bei RoR mittels des render-Befehl. Durch das in Rails verwendete Routing
von Benutzeranfragen würde es jedoch zu folgendem Verhalten kommen:
Angenommen wir fügen eine neue Meldung hinzu (URL: 127.0.0.1/newsadmin/new) und verwenden für die
Ausgabe der neuen Liste render (:action => 'list'), so wird beim Drücken der F5-Taste die Meldung erneut
hinzugefügt, da sich die URL nicht verändert hat!
Um dieses Verhalten einer Anwendung zu umgehen, existiert der Befehlt redirect_to.
Mittels dieses Befehls ist es möglich andere Funktionen innerhalb der Railsanwendung aufzurufen,
hierfür greift die Funktion auf das unter Routing vorgestellte url_for-Kommando zurück.
Beispiele:[top]
Flash
Ein anderer Aspekt einer Webanwendung ist die Rückmeldung an den Benutzer über den Status seiner
Anfrage, z.B. ob die Newsmeldung hinzugefügt wurde oder Fehler auftraten. Hierfür gibt es die
Flash-Variable.
Dieser Hash dient der Railsanwendung als Meldungspuffer. Die in ihm abgelegten Meldungen bleiben exakt
einen Funktionsaufruf erhalten und können so auch noch nach einem redirect_to zu einer Methode desselben
Controllers noch referenziert werden. Sollte eine Meldung über mehrer Funktionsaufrufe vorgehalten
werden, so muss die Flashmeldung mittels der Funktion flash.keep(:meldung) in dem aufgerufenen Controllern
erneuert werden. Die Funktion flash.now[:meldung] = "hello wourld!" stellt hierzu das genaue
Gegenteil dar, diese Meldung besteht nur noch bis zum Ende des Funktionsaufrufes.
Der Einsatz des flash-Hashes dient vor allem der Strukturierung der Anwendung, so ist es möglich die
einzelnen Bestandteile funktionsgebunden zu implementieren, d.h. eine Funktion für das Anzeigen der
News-Liste und eine für das Anlegen einer neuen News, ohne dass man sich Gedanken über die Kommunikation
zwischen den beiden Funktionen machen muss.
app/controller/newslist_controller.rbFlash über den Controller hinaus
Um Controller übergreifende Flash-Meldungen zu erzeugen, muss ein wenig getrickst werden. Hierzu muss
eine extra redirect-to-Methode in der vererbenden Klasse erzeugt werden. Im folgendem Beispiel soll
eine Methode redirect_to_login realisiert werden:
app/controllers/application.rb[top]
Filter / Verifikation
Analog zu der in Activ Record integrierten Verifikation, haben auch die Controller in Rails diese
Möglichkeit. Sie besitzen jedoch zusätzlich zur Verifikation noch Filter:
Filter
Diese Filter-Flag erlaubt das Aufrufen von beliebig vielen Methoden bevor/nach dem Ausführen
einer Aktion des Controllers. Sollte eine der aufgerufenen Filter-Methoden false liefern, so würde die
Verarbeitung an dieser Stelle unterbrochen.
Standardmäßig werden alle Methoden eines Controllers mittels der eingestellten Filter geprüft, da
dies nicht immer sinnvoll ist, können Ausnahmen wie folgt definiert werden:
Anmerkung: die Filter werden vom Elternobjekt auf das Kindobjekt vererbt.
Verifikation
Die Verifikationsfilter dienen der Vereinfachung, sie übernehmen die Aufgabe der überprüfung,
ob bestimmte benötigte Variablen im Controllerkontext bereitstehen. Normalerweise müsste hierzu
erst eine Methode geschrieben und diese als before_filter eingehängt werden. Der Aufbau
des Verifikatiosfilter soll am Beispiel verdeutlicht werden:
Umsetzung mittels Filter:Umsetzung mittels Verifikationsfilter[top]