|PHP| Schönere Strukturierung

  • Hey Com,


    ich frage mich schon seit längerem wie ich eine schönere Struktur zwischen PHP und HTML erreichen kann.


    Aktuell sieht das ganze bei mir folgendermaßen aus:



    HTML per echo ausgeben gefällt mir persönlich nicht, weil ich zum einen dadurch kein HTML Highlighting mehr hab und zum anderen es für mich nicht "richtig" aussieht.
    Wie handhabt ihr das? Irgendwelche Ideen?


    Liebe Grüße

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


    PHP
    <?=USERS::getAllCustomers()?>

    hat den gleichen Effekt wie ein Echo

    seekrass approved
    4x vom Discord geflogen


    shoxinat0r 4
    dennismitzwein 2
    Trooper[Y] 2
    maddin 1
    Unbekannter Discord Kick 2
  • Wenn du nur eine Variable Ausgeben musst kann ich dir sehr folgendes zu Herzen legen:


    PHP
    <?=USERS::getAllCustomers()?>

    hat den gleichen Effekt wie ein Echo

    Interessant!! Werde ich mal ausprobieren.


    Sonst eine Idee, wie ich die ständigen PHP tags öffnen, abfrage erstellen, tag wieder schließen, html code ausgeben, tag wieder öffnen abfrage beenden umgehen kann, dass es einfach strukturierter aussieht?`

  • 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)


    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 :D

    seekrass approved
    4x vom Discord geflogen


    shoxinat0r 4
    dennismitzwein 2
    Trooper[Y] 2
    maddin 1
    Unbekannter Discord Kick 2
  • 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)

    Ich hab mir mein eigenes Framework geschrieben, in dem ist auch ne Template Engine enthalten, es geht halt wirklich rein um kleinere Abfragen die auf der Seite selbst gemacht werden.
    Habe jetzt im Internet folgendes gefunden:


    PHP
    <? if($variable == 1):?>
    //HTML
    <? else: ?>
    //HTML
    <? endif ?>

    Finde ich persönlich recht ansprechend. Es irritiert nur das ganze ohne Klammern zu schreiben. Ich denke so werde ich das erstmal nutzen, schöner kann mans glaub nicht machen.

  • 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.

    • <? if($variable == 1):?>
    • //HTML
    • <? else: ?>
    • //HTML
    • <? endif ?>



      Ist auch ne gute Lösung, ABER es sieht nachher noch schlimmer aus wenn du es mehr als 5x verwenden musst in einer Seite.
      Ich kann dir echt nur Laravel empfehlen. Das ist Sturktur vom feinsten. Durch die Template Engine die Laravel verwendet (blade) kann man echt gut Strukturiert arbeiten.


      Weil OOP und mit Classes kennst du dich anscheinend gut aus.

  • 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)

    seekrass approved
    4x vom Discord geflogen


    shoxinat0r 4
    dennismitzwein 2
    Trooper[Y] 2
    maddin 1
    Unbekannter Discord Kick 2
  • 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

    Chief Technology Officer (CTO)


    Interesse an folgenden Domains?

    fivemp.de - planet-zoo.de

    Jetzt anschreiben :)

    Einmal editiert, zuletzt von Jony ()

  • 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.

    Ich bin
    .. seit etwa 2007 in der Webentwicklung tätig, seit 2013 professionell
    .. Erfahrener Entwickler in PHP, Swift, Javascript, Typescript und Ruby. Zusätzlich habe ich Erfahrung in Python, Java, C#, C++, Prolog und einigen esoterischen Programmiersprachen
    .. Luftfahrtenthusiast und Segelflieger