Laravel 5.2 Entwicklung

[gelöschter Benutzer]

Hallo!

Zunächst muss ich sagen das mir Laravel mal so überhaupt gar nicht gefällt.

-Die Datenstruktur ist extrem kompliziert
-Die Entwickler leugnen die Existenz von Debian Oldstable
-Unter Debian Oldstable wird einfach ohne Fehlermeldung eine veraltete Version installiert
-Selbst unter Systemen die ihnen in den Kram passen kann man es nicht über die Paketverwaltung installieren
-Die empfohlene Testumgebung ist eines Ubuntu VM die man mit einem System namens vagrant installieren soll (Die Argumentation dafür liest sich wie ein Witz)
...

Okay, hören wir mal mit dem Lästern auf und kommen zum Punkt:
Ich habe jetzt erfolgreich eine Testumgebung in einer Win7 32Bit VM aufgesetzt, alles funktioniert wie es soll.
Allerdings wird mir jetzt klar das man da wirklich um eine Seite hinzuzufügen Änderungen an mindestens 4
Dateien vornehmen muss. Übersehe ich da irgendwas gravierendes oder ist das wirklich so?

Besten dank im Voraus.

 

[Timon3]

Als jemand, der ziemlich oft und gerne mit Laravel arbeitet, kann ich ja mal Stellung nehmen

-Die Datenstruktur ist extrem kompliziert

Welche Datenstruktur? Wenn du den Ordner-Aufbau meinst: Das ist alles ziemlich logisch geordnet und PSR-4-konform. Ich weiß nicht, welche "Datenstruktur" du genau meinst, kannst du aber gerne schreiben. Vielleicht kann ich dir ja helfen, das besser zu verstehen.

-Die Entwickler leugnen die Existenz von Debian Oldstable

Inwiefern?

-Unter Debian Oldstable wird einfach ohne Fehlermeldung eine veraltete Version installiert

Von was? Laravel? Homestead? PHP?

-Selbst unter Systemen die ihnen in den Kram passen kann man es nicht über die Paketverwaltung installieren

Öhm, warum sollte man auch? Solche Sachen gehören in die Paketverwaltung der jeweiligen Sprache (also z. B. Composer), nicht in irgendwelche anderen Paketverwaltungen. Über Composer ist es auch kinderleicht, Laravel zu installieren.

-Die empfohlene Testumgebung ist eines Ubuntu VM die man mit einem System namens vagrant installieren soll (Die Argumentation dafür liest sich wie ein Witz)

Ist halt nur lustigerweise absoluter Standard in der PHP-Welt, über Vagrant (oder Docker) VMs zu benutzen für die Entwicklung. Das ist auch sehr sehr sinnvoll so, da das Entwicklungssystem dem Production-Environment wesentlich ähnlicher ist (bzw. leicht so angepasst werden kann), und es ist sehr einfach Änderungen vorzunehmen bzw. zu destroyen und neu zu provisionen, vor allem bei verschiedenen VMs.

Okay, hören wir mal mit dem Lästern auf und kommen zum Punkt:
Ich habe jetzt erfolgreich eine Testumgebung in einer Win7 32Bit VM aufgesetzt, alles funktioniert wie es soll.
Allerdings wird mir jetzt klar das man da wirklich um eine Seite hinzuzufügen Änderungen an mindestens 4
Dateien vornehmen muss. Übersehe ich da irgendwas gravierendes oder ist das wirklich so?

Du musst keine Änderungen an 4 Dateien vornehmen, eine einzelne Datei reicht - die app/http/routes.php. Du kannst bei jeder der normalen Routen-Methoden als zweiten Parameter eine Closure übergeben, welche ausgeführt wird. Macht halt nur niemand, weil es unsauber ist - stattdessen verfolgt Laravel (wie jedes moderne Web-Framework) eine MVC-Struktur. Das ist auch sehr sinnvoll so.

 

[gelöschter Benutzer]

Muss ich sehr wohl, der routes Eintrag macht die Seite nämlich lediglich theoretisch erreichbar. Dann muss ich immer noch:
-Tätsächlich eine möglichkeit zur Navigation dorthin geben für den Nutzer
-den Seiten Quellcode erstellen
-das Seiten Template erstellen

 

[alter_Bekannter]

Ist halt nur lustigerweise absoluter Standard in der PHP-Welt, über Vagrant (oder Docker) VMs zu benutzen für die Entwicklung. Das ist auch sehr sehr sinnvoll so, da das Entwicklungssystem dem Production-Environment wesentlich ähnlicher ist (bzw. leicht so angepasst werden kann), und es ist sehr einfach Änderungen vorzunehmen bzw. zu destroyen und neu zu provisionen, vor allem bei verschiedenen VMs.

Nicht in der zivilisierten Welt:

There are also significant differences in Linux preferences when looking at individual countries. Debian is the most popular system in Germany, France, Italy, Spain, Russia and Eastern Europe. CentOS is leading in Japan, China, India, Vietnam and UK, and Ubuntu in South Africa, Australia, Brazil, Argentina, Sweden and Norway. Red Hat is the most popular Linux distribution on .edu and .gov sites.

Quelle: https://w3techs.com/blog/entry/debi...erver_market_at_the_expense_of_red_hat_centos
Leider habe ich keine neueren Zahlen.

Von Laravel hab ich zwar keine Ahnung, aber du scheinbar ebensowenig von Serverumgebungen. Also müssen wir da wohl auf jemand anderes warten.

Und den Part mit den Paketverwaltungen meinst du hoffentlich nicht ernst. Oder du hast keine Ahnung was das bedeuten würde.

 

[werner]

Verstehe ich jetzt leider nicht. Was sagt eine Statistik über die meist genutzten Distributionen im Allgemeinen über die PHP Entwicklung aus?

 

[alter_Bekannter]

Weil heute keiner mehr statische Webseiten betreibt?

 

[fragkp]

Muss ich sehr wohl, der routes Eintrag macht die Seite nämlich lediglich theoretisch erreichbar. Dann muss ich immer noch:
-Tätsächlich eine möglichkeit zur Navigation dorthin geben für den Nutzer
-den Seiten Quellcode erstellen
-das Seiten Template erstellen

Ich glaube du missverstehst was Laravel ist. Es ist ein PHP-Framework und kein Klicki-Bunti-Template Generator. Natürlich musst du die Templates und Co selbst schreiben und ja auch die Navigation musst du selbst schreiben - genauso wie bei allen anderen PHP-Frameworks

 

[gelöschter Benutzer]

Was ist denn der nutzen?

Sehen manche diesen komische aufgezwungenen wannabee OOP Aspekt wirklich als Vorteil?
Das ist mein Problem, ich habe sowas schon komplett selber geschrieben und bei meinem Kram muss ich nicht alles an 4 Stellen ändern.

Laravel tut:
SQL Abstraktion -> pille palle, das macht man sowieso nebenher mit seinen eigenen Code Snippets
Authentifikation -> siehe oben

Was bleibt?

 

[fragkp]

Siehe: https://laravel.com/docs/5.1

Also wenn du das alles in der Qualität selbst geschrieben hast, Hut ab - das bezweifel ich aber.

 

[theSplit]

@fragkp:

Beim Arbeiten mit Python Frameworks ist es in der Regel das gleiche, man hat seine Routes die sagen was wo und wann ausgeliefert wird, man hat seine Templates extern defniert und dann noch Sachen wie die Webtechnik separat. Zum Beispiel Flask.

@Sieg

Vorteil?
Die Wartbarkeit, auch für ein Team, nur weil das Template zerschossen ist oder Fehler enthält kann man die anderen Teile komplett ignorieren und kümmert sich nur um das Template, kein Zwang überhaupt den Rouing Code anzufassen oder sich durch "x" Routen zu welzen, Server neu zu starten oder ähnliches.

Oder wenn du weitere Daten anfordern willst, du änderst dein Model Code entsprechend - und hast es dann in deinen Views zu Verfügung, überall theoretisch. Ohne das du die Templates angefasst hast oder deine Datenbank Zugriffe / Controllen. Es ist sauber voneinander isoliert und bleibt übersichtlich.

Warum benutzt man .h Files in C wenn ich alles in eine .c Datei kloppen kann? Steht doch alles drin.....
Man kann auch sagen Code-Organisation vereinfacht die Wartbarkeit, das Arbeiten mit dem Code-Parts, die alle schon eine "Aufgabe" haben noch bevor du sie überhaupt geschrieben hast, eine Struktur um genau zu sein.


Gibt mit Sicherheit noch mehr was für MVC spricht, aber die oberen Punkte fallen mir spontan ein.

Ist auch nicht nur Laravel spezifisch. Aber ich bin auch nicht der MVC Guru. Sollten aber valide Anmerkungen sein.

 

[Timon3]

Muss ich sehr wohl, der routes Eintrag macht die Seite nämlich lediglich theoretisch erreichbar. Dann muss ich immer noch:
-Tätsächlich eine möglichkeit zur Navigation dorthin geben für den Nutzer
-den Seiten Quellcode erstellen
-das Seiten Template erstellen

Natürlich musst du dem Nutzer die Möglichkeit geben, zu der Route zu kommen. Anders geht es nicht. Aber mehr als die routes.php musst du nicht ändern, um eine neue Seite hinzuzufügen - du könntest auch direkt darin deinen rohen Code schreiben. Ist natürlich nur kacke.

Nicht in der zivilisierten Welt:
Quelle: https://w3techs.com/blog/entry/debi...erver_market_at_the_expense_of_red_hat_centos
Leider habe ich keine neueren Zahlen.

Dann benutz doch dein tolles Debian oder was du auch willst? Meine Aussage war, dass das entwickeln in VMs absoluter Standard ist, und daran ändert auch deine Aussage nix. Die Basis der Entwicklungsumgebung ist meistens relativ egal, aber du kannst trotzdem nehmen was du willst. Lesen hilft meistens

Und den Part mit den Paketverwaltungen meinst du hoffentlich nicht ernst. Oder du hast keine Ahnung was das bedeuten würde.

Das Kompliment gebe ich nur gerne zurück. Wie sinnvoll ist es bitte, wenn ich ein Framework über eine distributions-eigene Paketverwaltung benutze? Ich benutze doch lieber den Paketmanager meiner Sprache, über den eh alle anderen Pakete geregelt wird, damit ich dann im Test-Environment updaten kann und dann in die Production deployen kann. Wo da der Sinn ist, über die Distribution selber zu gehen, ist mir komplett schleierhaft.

Was ist denn der nutzen?

Der Nutzen von Laravel ist simpel: Es nimmt dir verdammt viel Arbeit ab. Es gibt dir eine Struktur vor. Es liefert hochqualitative, gut getestete Komponenten mit (Router, Templating-Engine, DBAL, DI-Container, Migrations usw), die man für große Projekte nunmal braucht, wenn man ordentlichen Code schreiben will.

Sehen manche diesen komische aufgezwungenen wannabee OOP Aspekt wirklich als Vorteil?

Welches Wannabe-OOP? PHP ist eine Sprache, die man - bis auf den Einsprungspunkt - vollkommen objektorientiert benutzen kann und sollte.

Das ist mein Problem, ich habe sowas schon komplett selber geschrieben und bei meinem Kram muss ich nicht alles an 4 Stellen ändern.

Das würde ich wirklich gerne sehen, neue Frameworks sind immer cool. Wird bestimmt auch der restlichen PHP-Community gefallen.

Laravel tut:
SQL Abstraktion -> pille palle, das macht man sowieso nebenher mit seinen eigenen Code Snippets
Authentifikation -> siehe oben

Da liegt dein Fehler: Beschäftige dich erstmal damit, wie man ordentlichen Code schreibt, bevor du hier einen Rant als Frage versteckst. Die DB-Abstraktion ist sehr sinnvoll, damit du ggf beim Skalieren deiner Anwendung umsteigen kannst auf eine andere DB (beispielsweise benutze ich für Tests immer eine SQLite-Umgebung, damit ich meine echte Datenbank nicht berühre). Und es wird eben noch viel viel mehr geliefert, allein ordentliche Output-Sanitization usw... man muss es aber eben auch benutzen können.

 

[gelöschter Benutzer]

Das klingt zumindest in der Theorie sinnig. Leider hat man sich über den Aspekt der Lesbarkeit weniger sorgen gemacht als man beschlossen hat pseudo OOP im pseudokonversationellen Modus umzusetzen.

Ich hoffe das ich die Entscheidung auch eines Tages verstehe und das sie nicht ins Muster der PR Tweets passen.

 

[fragkp]

Du findest also OOP nicht lesbar als prozeduraler Code? Kann ich (und SEHR viele andere auch) absolut nicht nachvollziehen.
Warum das alles "pseudo" sein soll verstehe ich auch nicht.

Deine Posts lesen sich übrigens sehr nach dem Schema: 99% vs 1%

 

[gelöschter Benutzer]

Weil php im Webseitengebrauch im Pseudokonversationsmodus arbeitet der gerade in solchen Beispielen OOP Vorteile effizient eliminiert und nur überwiegend die Nachteile übrig lässt.

Die Vorteile von OOP liegen in beständigen Objekten mit variablen Eigenschaften.

 

[fragkp]

Naja, bin mal raus - Argumente gab es jetzt ja schon genug. Ist mir zu Pseudo hier...

 

[gelöschter Benutzer]

Und wie nennst du das Konzept sonst?

 

[Timon3]

@Sieg: OOP. Wenn du nur hier hin gekommen bist, um über PHP rumzutrollen (ja, PHP IST eine vollkommen objektorientierte Sprache), dann tut es mir echt Leid dass ich die Zeit verschwendet habe und versucht habe, dir zu antworten. Wenn man sich aber mental bereits gegen alles wehrt, was man nicht kennt, sollte man nun einmal erwarten, moderne Konzepte nicht unbedingt zu verstehen.

 

[virtus]

@Sieg mein Gott, piss doch nicht rum. Wenn du nicht damit klar kommst, zwingt dich ja niemand damit zu arbeiten. Hör auf rum zu heulen, koch deine eigene Suppe und wunder dich nicht, wenn dich die Konkurrenz abhängt.

Vagrant ist ein Wrapper für Virtualisierungssoftware, der vor allem ein einheitliches Interface zu deren Bedienung sowie Konfiguration darstellt.
Wenn dir das zu viel schwarze Magie ist, dann kannst du auch selbst eine VM aufsetzen und verwalten. Der Aufwand für dich wird dann lediglich um ein paar Dimensionen größer.

Warum nur bestimmte Betriebssysteme "unterstützt" werden? - Ganz einfach: Kapazitäten
Jedes System hat Eigenarten, die es von anderen Systemen unterscheidet. Das kann sich in grundlegenden Konzepten manifestieren oder es zeigt sich schlicht in der Verfügbarkeit von Abhängigkeiten, insbesondere deren Versionen und Schnittstellen. Natürlich ist es möglich eine Software so zu schreiben, dass sie unter (nahezu) jeglichen Systemen gleichermaßen funktioniert. Dazu benötigt man jedoch u.U. riesige Kapazitäten. Der erzielte Nutzen daraus ist in der Regel nicht ansatzweise verhältnismäßig. Da ist es besser die Software für ein System zu optimieren und die Entwicklungskapazitäten in die Verbesserung der Software zu investieren, als sich um die Anpassung an trölf Systeme zu kümmern.
Wie bereits gesagt wurde: Innerhalb einer VM oder eines Docker-Containers kann man sehr leicht die nötigen Voraussetzungen schaffen, die die Software benötigt. Die Erzeugung eines entsprechenden Images kostet den Entwickler keinen nennenswerten Mehraufwand. Auch für den Nutzer ist es einfacher eine VM oder ein Docker-Image zu deployen, als selbst manuell die nötigen Voraussetzungen zu schaffen.


Ja, PHP war nicht immer objekt-orientiert. Aber du solltest dich fragen, warum PHP gerade in der Objekt-Orientierten Programmierung in den letzten Jahren die größten Entwicklungen zu verzeichnen hat. Bestimmt nicht, weil die Entwickler Spaß an der Sache hatten.