Seit einiger Zeit möchte ich ein Projekt realisieren, und stolperte von Joomla zu CakePHP zurück zu Joomla, um dann bei Ruby On Rails zu landen (kurz RoR oder einfach Rails).
Mittlerweile bin ich gefesselt von Rails. Aber vorweg zur Frage, was denn Rails überhaupt ist, denn darin liegt ein großer Teil der "Kraft".
Ich möchte eine Internetseite programmieren, aber nicht einfach nur EINE Seite, sondern dynamisch erstellter Inhalt, der auch noch Inhalte je nach Auswahl an den Nutzer liefert.
Eine typische Anwendung ist ein Online-Shop, bei welchem der Nutzer Produkte in den Warenkorb "legt", um sie dann zu bestellen bzw. gemeinsam auf einer Rechnung an den Betreiber zu schicken.
Natürlich kann man dies alles "zu Fuß" machen, aber die ganzen Datenbankenrelationen im Hintergrund (Produkte, Kunden, Aufträge, Warenkörbe usw.) sind alleine schon genug, um verrückt werden zu können.
Joomla ist ein bekanntes CMS und gerade in der neusten Version eine super Geschichte, mit der man viel erreichen kann (gerade auch, weil es mittlerweile ein Framework besitzt und das CMS eigentlich nur noch ein Addon ist). Damit kann ich einfach ein paar mal klicken und bekomme eine komplette Seite fertig erstellt, auch Online-Shop o.ä.
Genauso ist CakePHP ganz toll, weil man schnell über Skripte fertige Bausteine erstellen kann. Eine einfache CRUD-Anwendung (CreateReadUpdateDelete) erreicht man durch EINEN Befehl.
In Rails verhält es sich ähnlich, viele Aufgaben müssen nicht neu erfunden werden, sondern können generiert werden, um nur noch Anpassungen durchführen zu müssen.
Aber auch wenn ich nun die Dateien von Joomla oder CakePHP nutzen könnte, um meine Vorstellungen umzusetzen, es also als Framework nutze, scheiterte ich oft an PHP.
Diese Skriptsprache "hacke" ich schon seit meinen frühen Studentenjahren und obgleich ich dazu auch schon paar Bücher gelesen habe, bin ich nie so richtig an einem Punkt angelangt, wo mir Sachen leicht fallen.
Wenn ich aber den Code anderer als Framework nutzen möchte, sollte ich die Sprache einigermaßen "sprechen" können.
Nun kommt Ruby ins Spiel, worin alles ein Objekt ist und man fast immer die Punkt-Notation nutzen kann, wie z.B. 2.times {puts "hi"} erzeugt hi, hi.
Auch fallen diese ewig blöden Klammern weg, die man sonst fast überall beim Code anderer Sprachen nutzen muss.
Ruby ist leserlicher und intuitiver.
Somit landete ich bei der Auswahl des Frameworks bei Rails,
und stieß auch gleich auf die ersten Hürden.
In Rails heisst es z.B. convention over configuration (wie auch bei CakePHP, aber weil CakePHP Rails als Vorbild hat, kein Wunder):
somit MUSS man sich an gewisse Regeln halten, damit Magie passieren kann.
Hierbei ist die Idee des MVC-Frameworks ebenso tragend wie der REST-Aspekt.
MVC bedeutet, dass das mODEL die Daten hat, die vom cONTROLLER angefordert worden sind und per vIEW an den Nutzer gehen.
Es sind also immer diese drei im Hintergrund, wenn eine Internetseite aufgerufen wird.
Dabei findet Rails diese Tripel selbständig, warum es eben auch Konvetionen für Namen gibt; dies hält den Code schlank.
REST hat bei mir etwas länger gedauert bis ich den Einsatz verstanden hatte. Es meint ganz einfach, dass Daten nicht per speziell implementierter API transferiert werden, sondern per URL und den HTTP-Headern bzw. ob es ein GET, POST, DELETE o.ä. ist.
Abschliessend kann ich jedeRM raten sich Ruby on Rails mal anzusehen, denn obwohl es teils steif wirkt, passieren die wunderbarsten Dinge im Hintergrund, ohne dass man sie programmieren musste.
Und gerade weil die Konventionen so steif sind, erreicht man schnell Erfolge und wenn man die Logik erstmal verstanden hat, versteht man die Erfolgsgeschichte RubyOnRails auch.
Mittlerweile bin ich gefesselt von Rails. Aber vorweg zur Frage, was denn Rails überhaupt ist, denn darin liegt ein großer Teil der "Kraft".
Ich möchte eine Internetseite programmieren, aber nicht einfach nur EINE Seite, sondern dynamisch erstellter Inhalt, der auch noch Inhalte je nach Auswahl an den Nutzer liefert.
Eine typische Anwendung ist ein Online-Shop, bei welchem der Nutzer Produkte in den Warenkorb "legt", um sie dann zu bestellen bzw. gemeinsam auf einer Rechnung an den Betreiber zu schicken.
Natürlich kann man dies alles "zu Fuß" machen, aber die ganzen Datenbankenrelationen im Hintergrund (Produkte, Kunden, Aufträge, Warenkörbe usw.) sind alleine schon genug, um verrückt werden zu können.
Joomla ist ein bekanntes CMS und gerade in der neusten Version eine super Geschichte, mit der man viel erreichen kann (gerade auch, weil es mittlerweile ein Framework besitzt und das CMS eigentlich nur noch ein Addon ist). Damit kann ich einfach ein paar mal klicken und bekomme eine komplette Seite fertig erstellt, auch Online-Shop o.ä.
Genauso ist CakePHP ganz toll, weil man schnell über Skripte fertige Bausteine erstellen kann. Eine einfache CRUD-Anwendung (CreateReadUpdateDelete) erreicht man durch EINEN Befehl.
In Rails verhält es sich ähnlich, viele Aufgaben müssen nicht neu erfunden werden, sondern können generiert werden, um nur noch Anpassungen durchführen zu müssen.
Aber auch wenn ich nun die Dateien von Joomla oder CakePHP nutzen könnte, um meine Vorstellungen umzusetzen, es also als Framework nutze, scheiterte ich oft an PHP.
Diese Skriptsprache "hacke" ich schon seit meinen frühen Studentenjahren und obgleich ich dazu auch schon paar Bücher gelesen habe, bin ich nie so richtig an einem Punkt angelangt, wo mir Sachen leicht fallen.
Wenn ich aber den Code anderer als Framework nutzen möchte, sollte ich die Sprache einigermaßen "sprechen" können.
Nun kommt Ruby ins Spiel, worin alles ein Objekt ist und man fast immer die Punkt-Notation nutzen kann, wie z.B. 2.times {puts "hi"} erzeugt hi, hi.
Auch fallen diese ewig blöden Klammern weg, die man sonst fast überall beim Code anderer Sprachen nutzen muss.
Ruby ist leserlicher und intuitiver.
Somit landete ich bei der Auswahl des Frameworks bei Rails,
und stieß auch gleich auf die ersten Hürden.
In Rails heisst es z.B. convention over configuration (wie auch bei CakePHP, aber weil CakePHP Rails als Vorbild hat, kein Wunder):
somit MUSS man sich an gewisse Regeln halten, damit Magie passieren kann.
Hierbei ist die Idee des MVC-Frameworks ebenso tragend wie der REST-Aspekt.
MVC bedeutet, dass das mODEL die Daten hat, die vom cONTROLLER angefordert worden sind und per vIEW an den Nutzer gehen.
Es sind also immer diese drei im Hintergrund, wenn eine Internetseite aufgerufen wird.
Dabei findet Rails diese Tripel selbständig, warum es eben auch Konvetionen für Namen gibt; dies hält den Code schlank.
REST hat bei mir etwas länger gedauert bis ich den Einsatz verstanden hatte. Es meint ganz einfach, dass Daten nicht per speziell implementierter API transferiert werden, sondern per URL und den HTTP-Headern bzw. ob es ein GET, POST, DELETE o.ä. ist.
Abschliessend kann ich jedeRM raten sich Ruby on Rails mal anzusehen, denn obwohl es teils steif wirkt, passieren die wunderbarsten Dinge im Hintergrund, ohne dass man sie programmieren musste.
Und gerade weil die Konventionen so steif sind, erreicht man schnell Erfolge und wenn man die Logik erstmal verstanden hat, versteht man die Erfolgsgeschichte RubyOnRails auch.
Kommentare
Kommentar veröffentlichen