Webentwicklung mit PHP - Übliche Vorgehensweise? (HTML mit PHP mischen)

[KROKvsKROK]

Hi,

Welches ist eigentlich die übliche Vorgehensweise in der Webentwicklung mit PHP?
Ist es dort üblich, dass man dort wild PHP Code mit HTML "Code" vermischt? Oder nutzt da so gut wie jeder ein externes Template-System wie z.b. smarty, womit man Logik und Darstellung sauber trennen kann?

 

[CooperakaTigger]

Für kleiner Projekte kann man es schon vermischen. Sobald das ein Projekt wird an dem mehrere Leute arbeiten und das auch schnell unübersichtlich wird empfehle ich ein Framework zu benutzen.
Grundsätzlich ist es natürlich immer gut die Logik von der Darstellung zu trennen, da du deine Darstellung dann nach belieben austauschen kannst.

Es kommt also drauf an was du umsetzten willst...

 

[Timmey92]

PHP ist von sich aus auch ein Template System. Du kannst auch in PHP wunderbar MVC anwenden, musst dich halt in den view Klassen darauf beschränken html code zusammenzubasteln, und nicht noch irgendwas zu berechnen, sondern reines auslesen des Models.

Richtig zu MVC gezwungen wirst du mit Frameworks wie Smarty.

 

[Daaron]

Für "Muttis kleine Homepage" kann man auch mal mischen. Aber spätestens wenn man in größerem Umfang Aktualisierungen an der Seite einplant, z.B. ein Newssystem, sollte man anständig arbeiten und möglichst sauber trennen.

Man muss aber nicht strikt nach MVC vorgehen. Im "Template" darf durchaus noch etwas PHP-Logik drin sein, z.B. um über ein Array von Bildern & Bildbeschreibungen in einem Galerie-Template zu iterieren. Nur so n Kram wie Datenbankzugriffe hat dann da wirklich nix mehr zu suchen.

 

[Blackbenji]

Wobei es meist einfacher ist, sich seine Logik selbst zu schrieben als in ein MVC einzuarbeiten und dann an die grenzen zu stoßen.
Da PHP ein eigenes Template System mit sich bringt ist es abhängig von dem was dazu noch kommt.
Für mich privat verzichte ich auf jegliches MVC und mach es lieber selbst.

 

[Backslash]

MVC und selbst machen sind völlig unabhängig voneinander und schließen sich deshalb auch nicht gegenseitig aus.

 

[Timmey92]

MVC ist einfach ein gutes und erprobtes Entwurfsmuster - "selbst machen" heißt für mich einfach nur frickeln und eine unwartbare Anwendung zu produzieren.

 

[Daaron]

Wobei es meist einfacher ist, sich seine Logik selbst zu schrieben als in ein MVC einzuarbeiten und dann an die grenzen zu stoßen.

...und wenn du nach 2 Jahren etwas ändern willst, guckst du wie's Schwein ins Uhrwerk. Und wo bitte bringt PHP ein eigenes Template System mit? Hab ich all die Jahre was verpasst?

 

[Blackbenji]

http://de.wikipedia.org/wiki/Template-Engine#Template-Engines_f.C3.BCr_PHP

Was meine Aussage angeht rudere ich ein Stück zurück, ich bin in dem Thema etwas in Richtung Framework abgedriftet auf basis von MFC, wo die Einarbeitung länger dauert als mal eben selber etwas zu schreiben.
MVC als Entwurfsmuster kann/sollte man natürlich immer anwenden - je nach Größe des Projektes.

 

[roker002]

Sorry aber an Templating kann PHP niemals ASP.NET schlagen.

 

[Daaron]

...und ASP.NET wird trotzdem immer das kleine rothaarige Stiefkind der Webentwicklung sein. Wer nur mit MS IIS zusammen spielen will ist doch eh für den Eimer.

 

[Timmey92]

Was Templating angeht kann ASP.NET niemals Java schlagen (und das meine ich sogar ernst, Spring + Apache Tiles etc. ist einfach krass geil).

Merkste selbst nicht wahr?

 

[Daaron]

Und auch Java ist eher eine Randerscheinung.... PHP ist der ewige Platzhirsch. Lediglich Ruby traue ich zu, es vom Thron zu stoßen.

 

[Tumbleweed]

Ich weiß ja, dass du Java nicht sonderlich magst, aber "Randerscheinung" wird Java nicht gerecht. Es gibt noch mehr als Kleinunternehmens-Websites aus Fertig-CMSen zu pressen. In dem Bereich hat PHP sich tatsächlich durchgesetzt, aus welchen Gründen auch immer (zur richtigen Zeit am richtigen Ort, leicht erlernbar, hosting simpel usw.). Im Backend bei großen eCommerce-Plattformen werkelt aber normalerweise Java bzw. eine andere JVM-Sprache (Scala ist z.B. im Moment sehr beliebt). Damit meine ich Shops bei denen es mit bloßer Einbindung eines PayPal-Buttons nicht getan ist.
Sprachen wie Ruby sind in der Rubrik völlig Fehl am Platz, schon wegen der anscheinend mageren Performance. In Benchmarks sehe ich Ruby zumindest normalerweise abgeschlagen. Zugegeben, selbst hab ich wenig Erfahrung mit Ruby, abgesehen von Chef und Puppet. Fürs Entwickeln mag es dem einen oder anderen ja gefallen, aber das ist eben nicht immer das entscheidende Kriterium.

 

[Daaron]

Ich weiß ja, dass du Java nicht sonderlich magst, aber "Randerscheinung" wird Java nicht gerecht.

Ich mag Java. Für sehr große und komplexe Projekte, z.B. ein CRM, ist es durchaus sinnig. Du verwechselst das mit C#, das ich für ne Pest halte...

Damit meine ich Shops bei denen es mit bloßer Einbindung eines PayPal-Buttons nicht getan ist.

...ist es bei Magento, osCommerce oder Contao Isotope auch nicht.
Du kannst aber in jeder Sprache Schund schreiben, genauso wie du in jeder Sprache Meisterwerke abliefern kannst.

Wenn wir schon von Shops sprechen: Amazon ist so ein Wunderwerk an Ambivalenz. Auf der einen Seite haben die richtig coole und innovative Tricks drin, z.B. wie die JS-Navigation mit "Dreiecks-Zone"... Auf der anderen Seite kann man da teilweise nicht sauber "zurück" drücken. Und spätestens als VERkäufer sieht man das wahre Elend. sellercentral.amazon.com ist totaler Reis. Ich hab da schon n gutes Dutzend Deadlinks gefunden, und du kannst dich mit Herstellernamen registrieren, die du danach im Frontend nicht anklicken kannst, um Produkte des Herstellers aufzulisten, denn sobald der Herstellername einen Bindestrich oder ein Leerzeichen hat klappt das halbe System zusammen.

Da ist es echt egal, ob die Java, PHP, Native C oder sonstwas verwenden, deren Programmierer haben echt n paar Schläge verdient.

Sprachen wie Ruby sind in der Rubrik völlig Fehl am Platz, schon wegen der anscheinend mageren Performance. In Benchmarks sehe ich Ruby zumindest normalerweise abgeschlagen

Neuere oder alte Versionen? So wie ich das sehe verfügt Ruby ab 1.9 über etwas, das ähnlich wie die OpCode Caches bei PHP funktioniert. Die Frage ist eher, wie sich z.B. Passenger gegen PHP-FPM stellt.