Hilfe beim Layout

[theHacker]

also praktisch im bereich php?

Böse.... aber leider richtig.

@SGDynamo1953:
Welchen Bereich sprichst du denn jetzt mit "einigen bereichen" an? Ich mein, hier gehts um die HTML-Ausgabe in PHP. Das würde bedeuten, du hast noch nie ein PHP-Script geschrieben, was eine Webseite als Ausgabe liefert. Kann ich mir nicht vorstellen.

 

[ZeroCCC]

Das würde bedeuten, du hast noch nie ein PHP-Script geschrieben, was eine Webseite als Ausgabe liefert. Kann ich mir nicht vorstellen.

Ich schon

 

[paigo]

@the"Hacker": Wieso ist include() nicht dafür gedacht, HTML-Dateien einzubinden? Ausserdem werden in meinem Beispiel PHP-Dateien eingefügt. Nichts gegen Smarty, aber das ist nur ein Layer für PHP und existiert nur zum Selbstzweck. Sieht halt gut aus, in so einer Programmbeschreibung: "Benutzt Smarty Templatesystem[...]".
Insgesamt gesehen tut es aber nichts anderes, als das Rad ein zweites Mal zu erfinden.

Das würde bedeuten, du hast noch nie ein PHP-Script geschrieben, was eine Webseite als Ausgabe liefert. Kann ich mir nicht vorstellen.

Für einen Hacker bist du erstaunlich fantasielos

 

[theHacker]

Nichts gegen Smarty, aber das ist nur ein Layer für PHP und existiert nur zum Selbstzweck. [...]Insgesamt gesehen tut es aber nichts anderes, als das Rad ein zweites Mal zu erfinden.

Es geht immer nur um Layer
Warum benutzt du ein Betriebssystem mit einer grafischen Oberfläche? Warum können darauf überhaupt mehrere Prozesse gleichzeitig laufen? Glaubst du, das Rad wurde um die 5x neu erfunden, bis du ein Paket über dein Netzwerk verschicken kannst, nur weil es x verschiedene Layer gibt? Wieso wurde die OOP "erfunden", wenn doch alles vorher schon ging? Wie viele Layer stecken in einem DBS drin? (...)

Das hat schon alles seinen Sinn.

Für einen Hacker bist du erstaunlich fantasielos

Du hast mich wohl falsch verstanden
Ich habe nicht gesagt, dass ich mir keine andere Verwendung für PHP vorstellen kann. Was ich gesagt habe, war, dass ich mir nicht vorstellen kann, dass SGDynamo1953 PHP schon jemals zu einem anderen Zweck benutzt hat.

 

[paigo]

Du hast mich wohl falsch verstanden

Das hab ich dann wohl.
Aber ein Templatesystem mit OOP zu vergleichen finde ich schwierig. Ganz davon abgesehen meinte ich, dass Smarty die Sache nicht vereinfacht, wie beispielsweise eine grafische Oberfläche für ein OS. Es bringt die gleichen Funktionen (eigentlich weniger) wie PHP mit, die Syntax ist lediglich anders. Trennung von Code und Layout, MVC, das geht auch alles (auch besser) ohne Smarty.

 

[ice-breaker]

Das hab ich dann wohl.
Aber ein Templatesystem mit OOP zu vergleichen finde ich schwierig.

finde ich gar nicht, beides erhöht die Code-Qualität immens und macht alles einfacher zu verstehen.

Trennung von Code und Layout, MVC, das geht auch alles (auch besser) ohne Smarty.

klar geht es ohne, aber was ist der Sinn von Smarty? Logik von Layout trennen. So und wenn ich nun nen User-Objekt an den View übergebe, der dann nen Attribut davon ausgeben soll, wo ist da meine Trennung?
Und Smarty hat noch nen viel größeren Nennwert, jemand mit nur HTML-Kenntnissen kann das Design anpassen, er muss nicht vorher PHP lernen, und gerade in Unternehmen ist sowas von Vorteil, denn man kann einem Grafiker doch net zumuten, der sowieso das Design macht und umsetzt auch noch PHP zu lernen um es einzubauen.

 

[tleilax]

Und Smarty hat noch nen viel größeren Nennwert, jemand mit nur HTML-Kenntnissen kann das Design anpassen, er muss nicht vorher PHP lernen, und gerade in Unternehmen ist sowas von Vorteil, denn man kann einem Grafiker doch net zumuten, der sowieso das Design macht und umsetzt auch noch PHP zu lernen um es einzubauen.

Sorry, aber hier muss ich auch mal reingrätschen. Wenn man das PHP-Templatesystem vernünftig baut, muss niemand "PHP lernen", um das Template ändern zu können.

Wo ist der Unterschied, ob ich das Smarty-Markup lernen muss oder ob ich die gleichen Funktionen via PHP-Code mache? Ich sehe hier den Vorteil, dass man ganz nebenbei rudimentäre PHP-Kenntnisse erlangt, wenn man auf Smarty verzichtet.

Beispiel:

// Smarty
<ul>
{foreach from=$foo item="item" key="key"}
  <li class="{if $key%2}event{else}odd{/if}">
    {$item.value}
  </li>
{/foreach}
</ul>

// PHP
<ul>
<?php foreach ($foo as $key=>$item): ?>
  <li class="<?=$key%2?'even':'odd'?>">
    <?=$item['value']?>
  </li>
<?php endforeach; ?>
</ul>

Wie man sieht, ist sich beides doch nicht so unähnlich und welches von beiden Markups man nun lernt, ist doch im Endeffekt wumpe.

Man verstehe mich nicht falsch. Ich mochte Smarty lange lange Zeit und habe es gerne eingesetzt, aber inzwischen komme ich mit "PHP-only"-Templates wesentlich besser klar und von Leuten, die meine Templates bearbeiten mussten, habe ich bislang noch keine Beschwerden gehört, dass es unlesbar oder unverständlich wäre.

Und grade bei bestimmten Partials, wie beispielsweise Pagination-Elementen, die einmal geschrieben werden und dann meistens so wie sie sind gut sind und nicht mehr verändert werden müssen, möchte ich die Möglichkeit(!) und die dadurch entstehende Flexibilität, Logik und Layout bewusst wieder zu vermischen, nicht mehr missen.

Quintessenz des Ganzen: Reine PHP-Templates müssen nicht unbedingt schlecht sein - natürlich unter der Prämisse, dass sie bewusst als Layer im System vorhanden sind und nicht einfach nur irgendwo mittendrin ein include reingeklatscht wird, welches auch noch Zugriff auf alle im System befindlichen Variablen hat...

 

[paigo]

[...]und nicht einfach nur irgendwo mittendrin ein include reingeklatscht wird, welches auch noch Zugriff auf alle im System befindlichen Variablen hat...

Nun ja, deswegen included man, wenn man diese Funktion benutzt, auch nur Dateien, die auf dem eigenen Server liegen. Bindet man ein Fremdscript ein, könnte dies die Variablenvererbung exploiten, das ist wahr.

Ansonsten stimme ich tleilax vollkommen zu, das Beispiel mit dem foreach() wollte ich auch schon bringen.

 

[tleilax]

Nun ja, deswegen included man, wenn man diese Funktion benutzt, auch nur Dateien, die auf dem eigenen Server liegen. Bindet man ein Fremdscript ein, könnte dies die Variablenvererbung exploiten, das ist wahr.

Das hatte ich als gegeben vorausgesetzt.

Ich meinte aber auch mehr, dass man den include nicht im globalen Namensraum ausführen sollte (was ja durchaus gerne mal gemacht wird), sondern immer in einer eigenen Funktion kapseln.

Zur Verdeutlichung:

private function render_template($filename, $variables)
{
	// [...]
	extract($variables);
	ob_start();
	include $filename;
	$content = ob_get_clean();
	// [...]

	return $content;
}

Wenn man das Ganze vernünftig aufsetzt (OOP), geht es gar nicht anders als eine äquivalente Lösung einzusetzen, aber bei wievielen Skripten sieht man nicht doch noch die "schönen" switch()/case-Blöcke und abschliessend ein include im globalen Namensraum.

 

[paigo]

Hm, das ist dann aber ein Problem, welches nur besteht, wenn man PHP-Dateien includet. Da könnten dann Kollisionen im Namespace auftreten (wenn man diesen nicht irgendwie standardisiert/dokumentiert hat, was wohl die wenigsten machen). HTML-Files gehen meiner Meinung nach aber klar. Wobei man da auch oft genug sieht, dass da völlig eigenständige Seiten inkludiert werden, und die page auf einmal zwei Header, vier body-tags, etc. bekommt.