|PHP| Schönere Strukturierung

Wenn du nur eine Variable Ausgeben musst kann ich dir sehr folgendes zu Herzen legen:

<?=USERS::getAllCustomers()?>

hat den gleichen Effekt wie ein Echo

Naja wenn du es ganz Strukturiert haben willst dann gibt es genügend Template Engines auf dem Markt.
Zu empfehlen ist es auch gerade bei mehreren Pages zum beispiel eine Variable (oder include / require) für Footer, Header zu haben (Sachen die auf allen Seiten existieren, oft sehr statisch)

Ganz schön wird es nie. Auch nicht mit Template Engines. Ich arbeite ja eigentlich fast nie mit Template Engines, da ich von den Sachen die diese haben nur einen kleinen Bruchteil brauche.
Da wird mir dann einfach zu viel Code ausgeführt den ich nicht brauche (bin ne Performance-Hure)

Zitat von Sinister

PHP tags öffnen, abfrage erstellen, tag wieder schließen, html code ausgeben, tag wieder öffnen abfrage beenden umgehen kann

Bezüglich dessen.
Ich bin heutzutage der Meinung das die meisten Rechner genug Leistung haben um solch Zeugs selbst zu machen.
Daher wird bei mir vieles über AJAX nachgeladen (dann wenn es gebraucht wird) und von dem Client in Lesbares HTML umgewandelt (Server versendet nur JSON)
So hat mein Server weniger zu Arbeiten und die Performance bleibt besser bzw geht zu Lasten des Clients

Benutz einfach eine Template Engine bzw. direkt die große Keule (Frameworks wie Laravel). Die Performance Einbußen sind schlicht vernachlässigbar. Wer sich darüber aufregt optimiert am falschen Ende, da wäre es geschickter bei den meisten Use Cases weg von dicken Serverlastigen PHP Seiten zu gehen, hin zu Microservices und einem Single Page Ansatz bzw. möglichst viel asynchron über JS dazu zu ziehen.
Da ist schlicht die Skalierbarkeit, Austauschbarkeit, Testbarkeit und vermutlich auch die gesamte Performance im Schnitt deutlich besser.

Zitat von fnL

da wäre es geschickter bei den meisten Use Cases weg von dicken Serverlastigen PHP Seiten zu gehen, hin zu Microservices und einem Single Page Ansatz bzw. möglichst viel asynchron über JS dazu zu ziehen.

Genau das hab ich noch nachträglich rein-editiert.
Wobei bei zu viel JavaScript darauf geachtet werden muss ob alles IE Kompatibel ist, falls man IE noch unterstützen will. (Wobei AJAX eig. nicht das Problem sein sollte)

Zitat von fnL

Benutz einfach eine Template Engine bzw. direkt die große Keule (Frameworks wie Laravel). Die Performance Einbußen sind schlicht vernachlässigbar. Wer sich darüber aufregt optimiert am falschen Ende, da wäre es geschickter bei den meisten Use Cases weg von dicken Serverlastigen PHP Seiten zu gehen, hin zu Microservices und einem Single Page Ansatz bzw. möglichst viel asynchron über JS dazu zu ziehen.
Da ist schlicht die Skalierbarkeit, Austauschbarkeit, Testbarkeit und vermutlich auch die gesamte Performance im Schnitt deutlich besser.

Von einem Problem in das nächste, ist auch keine Lösung

Man muss halt schauen, was für eine Anwendung man am Ende haben möchte. Frameworks machen bei kleineren Projekte einfach keinen Sinn. Alleine der Aufwand für die Konfiguration/Programmierung verschlingt zuviel Zeit. Von den unnötigen Ressourcen mal ganz abgesehen.
Die Entscheidung eine Clientseitige-Anwendung oder Serverseitige-Anwendung zu machen, sollte auch gut überlegt werden. Es kommt auf das Projekt an sich an. Pauschale Aussagen kann man da schwer treffen.

//edit:
Eine interessante Diskussion dazu: https://softwareengineering.st…en-not-to-use-a-framework

Wenn es um kleine Projekte ohne viel Konfiguration und Boilerplate geht, nutz ein Mini-Framework wie Slim oder Laravel Lumen. Mit Composer installieren und fertig. Mit Slim habe ich nicht all zu viel Erfahrung, aber mit Lumen brauchst du nichts konfigurieren für kleine Projekte, einfach anfangen zu coden reicht. Ich habe neulich die Webseite eines Kunden für leichtere Erweiterbarkeit in der Zukunft auf Lumen umgehoben, was mich insgesamt etwa 1-2 Stunden Arbeit gekostet hat. Genau für kleine Projekte sind solche Mini-Frameworks ja da. Und wenn du soweit bist, dass du in deinem Template mit echo USERS::getAllCustomers() rumhantieren musst, dann ist es wohl kein so kleines Projekt, dass nicht zumindest ein Mini-Framework gerechtfertigt wäre.

Der Hintergrund eines Frameworks ist so ziemlich immer Arbeitsaufwand zu sparen, weil das Rad nicht immer wieder neu erfunden werden muss. Häufig verwendete Komponenten anderer Entwickler werden dort verwendet wo man sie benötigt. Wenn ein Framework dabei zu viel ist, binde nur die Komponenten ein die du brauchst, gerade die Symfony Components sind alle sehr gut als einfache Drop-In-Lösungen konzipiert und machen einiges an Entwicklung einfacher. Template und Code zu trennen verringert den Arbeitsaufwand zwar nicht großartig, dafür aber die Sauberkeit des Codes- Und das ist hier gewünscht. Ist ein komplettes Framework, selbst wenn dieses auch fast nur aus einer Ansammlung von kleineren Bibliotheken besteht, zu viel, sollte eine einfache Template-Engine wie Twig doch ausreichen.

Zu der Diskussion im StackExchange: Gerade bei PHP machen die meisten der dort aufgeführten Punkte nicht viel Sinn. Frameworks werden als schlecht in manchen Fällen hingestellt, weil sie den Entwickler dazu bringen, nur noch im Framework zu denken und sich nicht mehr mit der darunterliegenden Materie beschäftigen. PHP bekommt seinen überwiegend negativen Ruf gerade davon, dass es so einfach ist darin einzusteigen und schnell verbuggte und sicherheitstechnisch kritische Seiten zu erstellen, weil man es machen kann wie man es möchte. Von meinen 10 Jahren PHP-Entwicklung waren die ersten ~5 Jahre genau das. Erst wenn man sich wirklich OOP-Konzepte einverleibt und sich anschaut, wie es von Open Source Projekten richtig gemacht wird (und einige Dinge quasi-standardisiert werden, siehe PHP-FIG), kommt man dazu wirklich skalier- und wartbare Webapplikationen zu schreiben. Gerade um da reinzukommen und den Sinn der ganzen abstrakt scheinenden Konzepten zu verstehen, eignen sich Frameworks. Und wer als Entwickler weiterkommen möchte, wird sich automatisch auch über die Zeit mit den darunterliegenden Strukturen beschäftigen, sodass er weiterhin die Arbeitserleichterung des Frameworks zu schätzen weiß, und gleichzeitig versteht, was unter der Haube überhaupt passiert.