ReLast - Klassik

Rails (Ruby on Rails)

Prinzipien

Rails verwendet drei übergeordnete Prinzipien:

  • Konvention über Konfiguration

    Durch die Konsequente Einhaltung der vorgegebenen Konventionen ist das Framework in der Lage viel zu "wissen". Wenn der Entwickler sich beispielsweise an die Konventionen zur Dateiablage und Namensgebung hält weiß das Framework wo es bestimmte Dateien findet und wie sie heißen. Der Entwickler muss diese Informationen nicht in einer Konfiguration hinterlegen.

  • DRY (Dont Repeat Yourself) Das DRY-Prinzip wird durch eine hohe Modularisierung des Codes erreicht. Code-Abschnitte können beispielsweise in "Helper" und "Partials" ausgelagert werden, wodurch die Wiederverwendbarkeit erhöht wird. Durch das erste Prinzip der Konvention wird die Verwendung des modularisierten Codes vereinfacht.
  • MVC-Struktur

    Die aus anderen Sprachen bekannte MVC-Struktur folgt auch in Rails der klassischen Einteilung in Model, View und Controller.

Konventionen

Eine Reihe von Konventionen in Rails:

  • Variablen
    • Klein, Worte durch Unterstrich trennen.
  • Klassen und Module
    • Groß, Worte durch CamelCase trennen.
  • Tabellen
    • Klein, Worte durch Unterstrich trennen, immer im Plural.
  • Dateinamen
    • Klein, Worte durch Unterstrich trennen.
  • Klassenname AdventureTrip, bedeutet das:
    • die dazugehörige Datenbanktabelle adventure_trips heißen würde (der Name des Models wird in Kleinbuchstaben umgewandelt, die einzelnen Wörter werden durch Unterstriche miteinander verbunden und in den Plural gesetzt).
    • die Klasse in der Datei app/models/adventure_trip.rb definiert ist.
  • Controller mit dem Klassennamen FlightsController, bedeutet:
    • Die Controller-Datei heißt flights_controller.rb und befindet sich im Verzeichnis app/controllers .
    • Das zugehörige Helfermodul heißt FlightsHelper und wird in der Datei flights_helper.rb im Verzeichnis app/helpers definiert.
    • Die dazugehörigen Templates (Views) befinden sich im Verzeichnis app/views/flights.
    • Wenn die Datei app/views/layouts/flights.html.erb existiert, wird diese Layout-Datei für alle Templates des Flights-Controllers verwendet. Andernfalls wird app/views/layouts/application.html.erb verwendet.
  • kein require erforderlich
    • In »normalem« Ruby-Code müssen wir, bevor wir auf Klassen oder Module zugreifen, diese über das Keyword require inkludieren. Da Rails die Beziehungen zwischen Dateinamen und Klassennamen kennt (wegen der Konventionen), ist das normalerweise in einer Rails-Applikation nicht nötig. Stattdessen leitet Rails beim ersten Aufruf einer unbekannten Klasse oder eines unbekannten Modul aus deren bzw. dessen Namen den entsprechenden Dateinamen ab und versucht, die Datei im Hintergrund zu laden. Deshalb können Sie einfach eine Klasse aufrufen, und schon wird die Klasse in Ihre Applikation geladen.
    • Das ist normalerweise so. Die einzige Ausnahme bildet Code im Verzeichnis lib und dessen Unterverzeichnissen. Da Rails diesen Bereich nicht verwaltet, müssen Sie die Klassen, die Sie aus diesem Verzeichnis nutzen wollen, über require einbinden: require "klasse_aus_lib_verzeichnis". Das gestattet die Ablage von eigenen Bibliotheken unabhängig von Rails.

DRY

Zwei praktische Beispiele für die Umsetzung des DRY-Prinzips:

Helper

Zum Beispiel der Application-Helper in app/helpers/application_helper.rb

# Methods added to this helper will be available to all
# templates in the application.
module ApplicationHelper
  def german_time(time)
    time.strftime("%d.%m.%Y %H:%M")
  end
end

Seit Rails 2.0 werden automatisch alle Helper-Dateien aus dem Verzeichnis app/helpers geladen. Es spielt daher im Prinzip keine Rolle, in welcher Helper-Datei Sie die Helper-Methoden definieren. Es ist jedoch üblich, Helper-Methoden, die nur für einen bestimmten Controller, z. B. für den Bookmarks-Controller, bestimmt sind, in der Datei bookmarks_helper.rb abzulegen. Helper, die Controller-übergreifend verwendet werden können, werden oft in der Helper-Datei application_helper.rb definiert. Man könnte auch eine Helper-Datei nur für Formatierungshelper, wie z. B. formattings_helpers.rb , erstellen.

Partials

Per Konvention mit einem Unterstrich versehene Dateien die Teilbereiche einer View auslagern. Die Partials werden von der View aufgerufen, beim Aufruf wird der Name ohne Unterstrich angegeben.

Das Partial _form.html.erb kann aufgerufen werden mit:

<%= render :partial => "form" %>

Es können auch Parameter übergeben werden. Zum Beispiel die Ziel-URL eines Formulars:

<% form_for :bookmark, :url => url do |f| %>
<%= render :partial => "form", :locals => {:url => {:action => "create"}} %>
<%= render :partial => "form", :locals => {:url => {:action => "update", :id => @bookmark.id}} %>

Ein weiteres Beispiel mit angepassten Buttons:

<%= submit_tag submit_text %>
<%= render :partial => "form", :locals => {:url => {:action => "create"}, :submit_text => "Neuen Favorit erstellen"} %>
<%= render :partial => "form", :locals => {:url => {:action => "update", :id => @bookmark.id}, :submit_text => "ändern"} %>

Ein Beispiel für Array-Ausgabe:

<li>
  <%= link_to h(bookmark.title), h(bookmark.url) %> 
  (
  <%= link_to "Details", :action => "show", :id => bookmark.id %> 
  |
  <%= link_to "ändern", :action => "edit", :id => bookmark.id %> 
  |
  <%= link_to "löschen", {:action => "destroy", :id => bookmark.id}, :confirm => "Wollen Sie diesen Datensatz wirklich löschen?" %>
  )
</li>

<ul>
  <%= render :partial => @bookmarks %>
</ul>

MVC-Struktur

Die MVC-Struktur wird in Rails über folgende Aufteilung realisiert:

  • Modell (ActiveRecord::Base)
  • View (eRuby, HTML)
  • Control (ActionController::Base)

Umgebung

Rails-Konsole

ruby script/console

Als Default wird die Entwicklungsumgebung geladen. Explizite Umgebungen laden mit: 

ruby script/console development
ruby script/console test
ruby script/console production

Debugging

In Rails wird der Ruby-Debugger eingesetzt.

Logging

Beim Generieren einer Rails-Applikation wird für die drei Standardumgebungen im Verzeichnis "log" eine eigene Logdatei angelegt:

  • log/development.log
  • log/production.log
  • log/test.log

Es wird immer in die zu der Umgebung gehörende Logdatei geschrieben, in der der Server gestartet wurde.

Rails protokolliert in den Logdateien sehr viele Informationen, wie z. B., welche URL aufgerufen wurde, welcher Controller und welche Action ausgeführt wurden oder welche SQL-Befehle ausgeführt wurden.

Eigene Einträge

Mit Hilfe des Objekts logger kann man eigene Einträge in der Logdatei vornehmen. Drei Methoden:

  • logger.info(text)

    Um allgemeine Informationen zu protokollieren.

  • logger.warn(text)

    Um Warnungen, dass z. B. etwas nicht funktioniert wie erwartet, zu protokollieren.

  • logger.debug(text)

    Um Variablen auszugeben, die der Fehlersuche dienen können. Standardmäßig wird dieser Befehl in der Produktionsumgebung ignoriert, d. h., es wird kein Eintrag in der Logdatei vorgenommen.

Aufruf:

logger.debug("User-id = #{user.id}")

Beispiele

Es ist jetzt <%= Time.now %>. Und so ..

<% 3.times do %>
Ho! 
<% end %>

View-Helper

Rails stellt eine Reihe von Helper-Methoden, die wir in den View Dateien benutzen können:

Format Helper, z.B.:

<%= distance_of_time_in_words(time.now, Time.now + 33, true) %>

Die debug-Methode

<%= debug(params) %>

Link-Helper

<%= link_to "kommentieren", :action => "add_comment" %>

Sylesheeet Link-Helper

<%= stylesheet_link_tag "schedule", :media => "all" %>

Pagination-Helper

<%= pagination_links(@user_pages) %>

Formatvorlagen

Formatvorlagen(templates) und wo sie stehen. TODO ..

Weblinks

Copyright © 2024

Datenschutz | Impressum