PHP & HTML in einer Datei

InsaYn

Grünschnabel
Hallo Community,

ich arbeite seit einigen Jahren hobbymäßig mit den verschiedenen Programmierspachen und habe PHP & HTML stets getrennt.

Meine Frage nun:
- ist es sinnvoll und nützlich PHP & HTML in einer Datei zu verwenden?
- welche Vor- bzw Nachteile hat diese Methode

Ich bin kein Profi, ich würde gerne mal die Meinung von Leuten lesen die sich da doch auf einem höheren Level als ich befinden, damit ich mich weiterbilden kann.

Ich freue mich auf eure Kommentare und Meinungen

Grüße
 
Warum soll nicht sinnvoll sein, das in einer Datei zu verwenden? In den meisten Fällen läßt es sich gar nicht vermeiden, da oftmals variable Daten aus einer Datenbank in den Quelltext eingebaut werden müssen.
Natürlich läßt sich das komplett auslagern und dann mittels Ajax einfügen, was aber mMn viel umständlicher ist und auch mehr Zeit erfordert, da auch mehr Daten hin und her geschickt werden müssen.

Für mich ist der einzige Nachteil, daß man zum Teil sehr lange Quelltexte von ein paar tausend Zeilen bekommt und die Übersichtlichkeit darunter leiden kann.
Bei so langen Quelltexten, bei denen bei mir PHP meistens den geringsten Teil ausmachen, bin ich inzwischen auch dazu übergegangen, das aufzutrennen und Teile per Ajax nachzuladen. Und für die Übersichtlichkeit ist man ja teilweise auch selbst verantwortlich. Konsequente Einrückungen per Tabs (Leerzeichen blähen die Dateigröße zu stark auf) und Leerzeilen können bei der Lesbarkeit sehr hilfreich sein.
 
Zu viel nichttriviales PHP eingebettet in HTML-Code führt typischerweise zu Spaghetticode, der tausende Zeilen lang ist, schlecht zu warten und umzuändern ist.

Ich denke, in größeren Applikationen sollte man irgendetwas der Bauart MVC-Muster befolgen und der einzige PHP-Code, der in HTML eingebettet ist, sollte der von Views sein.

PHP vereinigt hier zwei Konzepte: eine Sprache zur serverseitigen Programmierung an sich (wenn .php-Dateien mit nur PHP) und eine Templatesprache (wenn in HTML eingebettet).
Das ist zwar praktisch hin und wieder, erzeugt aber auch das Risiko, dass man beide Konzepte vermischt und dann in Spaghetticode landet.
 
Ich arbeite seit Jahren mit einem von mir gebauten CMS was ich stetig ausbaue und weiterentwickle. Dort habe ich strickt alle Datei-Typen getrennt. Ich hinterlege in den HTML Dateien Platzhalter, die ich am Ende durch str_replace() mit den Daten aus den PHP-Dateien und JS-Dateien füttere. So besteht der Quellcode am Ende gut und gerne mal aus 20 unterschiedlichen HTML- & JS Dateien. Header, Footer, Navi, Content, .... Bin bisher immer ganz gut damit gefahren. Habe mich nur gefragt ob ich mir am Ende viel zu viel Arbeit mache.

Ganz karer Vorteil meinerseits ist ganz einfach die Tatsache, dass ich kleine und übersichtliche Dateien habe. Und dadurch das ich meinen fertigen View aus vielen Segmenten zusammensetze, kann ich dieses einzelnen Segmente auf diversen Seiten verwenden.
 
@InsaYn Das hört sich genau nach dem an, was so typische client- und serverside Frameworks in dem Bereich auch tun! Zum Beispiel die modulare Zusammensetzbarkeit der Komponenten ist bekannt unter "html components" und wird von Angular (und vielen anderen Frameworks) exzessiv benutzt.
Typischerweise besitzen solche Frameworks auch Templating Engines, die mehr als nur Platzhalter + string replacement können. Diese können z. B. auch Listen entgegennehmen, sortieren, filtern und in ein <select>-Element schreiben.
 
Zurück