if abfrage über ?>
- Ersteller supertobs
- Erstellt am
mermshaus
Senior HTML'ler
Ja, gibt es. Zum Beispiel so. ;)
Hilfreich ist da manchmal die alternative Syntax:
- PHP: Alternative syntax for control structures - Manual
Ein <?php endif; ?> ist gerade bei langen HTML-Code-Bereichen aussagekräftiger als ein <?php } ?>.
Edit: Der Nutzen liegt etwa darin, PHP als Template-Sprache zu verwenden.
Etwas dämliches Beispiel (habe gerade nichts anderes greifbar):
Hilfreich ist da manchmal die alternative Syntax:
- PHP: Alternative syntax for control structures - Manual
Ein <?php endif; ?> ist gerade bei langen HTML-Code-Bereichen aussagekräftiger als ein <?php } ?>.
Edit: Der Nutzen liegt etwa darin, PHP als Template-Sprache zu verwenden.
Etwas dämliches Beispiel (habe gerade nichts anderes greifbar):
PHP:
<?php
$data = array(
180 => 'Description for id',
204 => 'Description for id',
208 => 'Description for id',
116 => 'Description for id'
);
?><!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Image Gallery</title>
<link type="text/css" rel="stylesheet" href="styles.css" media="screen" />
</head>
<body>
<div class="logo">
<h1>Demo</h1>
</div>
<div class="content">
<?php foreach ($data as $k => $v) : ?>
<div class="entry clear">
<div class="image"><img src="images/image-<?php echo $k; ?>.jpg" alt="" /></div>
<?php if ($v !== '') : ?>
<div class="description"><p><?php echo $v; ?></p></div>
<?php endif; ?>
</div>
<?php endforeach; ?>
</div>
</body>
</html>
Degers
Mitglied
Sind Codeunterbrechungen in irgendeiner Form schädlich bzw. destruktiv?
Bei längeren Html-Blöcken finde ich sie erstmal hilfreich, da im Editor das Highlighting läuft (Im Gegensatz zur Nutzung von echo oä), außerdem kann ich mir vorstellen, dass es einen Geschwindigkeitsvorteil bringt, wenn der Parser weniger durcharbeiten muss. Das ist eine reine Vermutung, zur Belegung der Theorie reichen meine Kenntnisse nicht aus.
mermshaus
Senior HTML'ler
Code-Unterbrechung riecht eben immer etwas nach Verletzung des EVA-Prinzips. Das heißt, Ausgaben beginnen, während noch nicht sämtliche Verarbeitungslogik abgelaufen ist. Tritt dann in der Verarbeitung ein Fehler auf, der eine Weiterleitung auf eine Fehlerseite auslösen sollte, geht das nicht, weil eben die Ausgabe schon läuft und deshalb keine Header mehr gesetzt werden können.
Deshalb sollte zwischen den Rollen von PHP als serverseitiger Skriptsprache (Anwendungslogik) und als Templatesprache (Einsetzen der ermittelten Daten in die Ausgabe) möglichst genau unterscheiden werden.
Deshalb sollte zwischen den Rollen von PHP als serverseitiger Skriptsprache (Anwendungslogik) und als Templatesprache (Einsetzen der ermittelten Daten in die Ausgabe) möglichst genau unterscheiden werden.
Wieso das? Wie unterbrichst Du deinen Code bzw. wie fütterst Du deine Templates mit Daten?
Das kommt drauf an wie Du sie einsetzt. Wenn du die Gesamte oder eine großen Teil der Logik in die Darstellung-Schicht steckst, ist es destruktiv. Arbeitest du hingegen z.B. mit dem Template-View Pattern und setzt du eventuell auch noch interceptor-Methoden wie __get ein, dann ist das durchaus positiv - dann merkt man auch das Template Engines wie Smarty ziemlicher Mist sind.
PHP: <p><?php $this->var; ?></p>
Smarty: <p> {$var}<p>
Mit der PHP Variante ist man da klar im Vorteil:
1) performanter
2) Syntax-Highlighting
3) durchs <?php erkennt man schon mal, dass es sich hier um eine Scriptsprache handelt
4) mit der Interceptor-Methode kann der Programmierer festlegen, auf welche Daten zugegriffen werden soll.
Zuletzt bearbeitet:
XraYSoLo
Senior HTML'ler
gar nicht, weil ich aus performance-gründen keine templates verwende und mir auch niemand im code rumschreiben muss und demnach der einzige bin, der ihn zu verstehen hat.
zum parser: dem ist das relativ egal, was und wie viel durch ihn durchgejagt wird. alleine schon eine konforme dateiendung sorgt dafür, dass sämtlicher code - auch reines HTML, da muss dann nicht mal PHP dabei sein - durch den parser durchrauscht. aktiviert wird er ohnehin. richtige "fresser" sind dann eher verschachtelte kontrollstrukturen oder quer durch das dokument definierte variablen, die durch ungeünstige position (NACH der verwendung definiert) einen zweiten durchlauf erzwingen.
außerdem sollte es irrelevant sein, ob man nun 1.000 zeilen PHP-code hat oder 1.100 mit ein paar HTML-tags drin.
Nils aka XraYSoLo
mermshaus
Senior HTML'ler
XraYSoLo schrieb:
Das Performance-Argument ist allgemein nicht haltbar. Gegen die Nutzung von Templates (welcher Art auch immer) spricht objektiv überhaupt nichts, eher im Gegenteil.
Darüber wird so oft diskutiert, auch etwa im Zusammenhang mit der Frage, ob Objektorientierung wegen der „Performance-Nachteile“ vielleicht nicht genutzt werden sollte. Wenn ich da sage, dass jede Abstraktion unvermeidlich einen gewissen Overhead verursacht, fühlen sich Leute, die entsprechend argumentieren, nur wieder bestätigt. Deshalb relativiere ich da schon gar nicht mehr.
Natürlich ist niemand gezwungen, Abstraktionstechniken zu nutzen. Aber die Argumente dagegen sind sozusagen unvorhanden. Die passende Frage, die einer Begründung bedarf, ist prinzipiell nicht „Warum nutzen?“, sondern „Warum darauf verzichten?“.
Wie meinst du das?
S
sysop
Guest
Als Firmenchef z.B. würde ich dir jetzt heftigst wiedersprechen, da du auf diese Art gegen die Firma arbeitest.
Jeder, der etwas von PHP versteht muss deinen Code lesen und ändern können, was übrigens auch sehr für die abstrahierung (OOP) sprechen würde.
Verständlicher Code ist auch eine Frage der Ehre
Ich betrachte es aber auch nicht als Dogmenbruch, wenn man in einigen Fällen Logik im Template unterbringt (z.B. die Ausgabe eines Eingabefehlers wenn vorhanden etc.). Das ist aber wohl auch eine Frage der Philosophie ähnlich wie OOP
NetAktiv
Senior HTML'ler
Wenn man beispielsweise in einer PHP-Datei sowohl die Dateneingabe (HTML-Form) als auch die Verarbeitung haben will, dann macht das sehr wohl Sinn. Man hat dann die folgende Struktur
PHP:
<?php
include('header.php');
if (form-not-empty) {
//verarbeite-form-data
} else {
?>
<!-- Anzeige HTML mit Form -->
<?php
}
include('footer.php');
?>mermshaus
Senior HTML'ler
Das widerspricht allerdings dem EVA-Prinzip. Besser:
Das Entscheidende ist dieser „Cut“, der eine Schnittstelle zwischen Verarbeitung und Ausgabe darstellt, indem alle relevanten Daten übergeben werden. Wie die Schnittstelle im Endeffekt umgesetzt wird, ist egal. Das kann auch ein Funktionsaufruf renderTemplate($templateFile, $vars);, eine Template-Engine oder was auch immer sein.
PHP:
<?php
$tpl['formShow'] = true;
$tpl['formSent'] = false;
$tpl['formErrors'] = array();
if (/* Formular gesendet */) {
$tpl['formSent'] = true;
// Verarbeitung, gegebenenfalls $tpl['formErrors'] befüllen und entscheiden,
// ob Formular angezeigt werden soll
}
// Ab hier ist der Verarbeitungsteil beendet und der Ausgabeteil beginnt.
// Von der Vorstellung her "kennt" der Ausgabeteil nun nur noch die
// $tpl-Variable, die die Schnittstelle zwischen Verarbeitung und Ausgabe bildet
?>
<?php include('header.php'); ?>
<?php if ($tpl['formSent']) : ?>
<?php if (count($tpl['formErrors']) === 0) : ?>
<!-- Es sind Fehler aufgetreten -->
<?php else : ?>
<!-- Alles okay -->
<?php endif; ?>
<?php endif; ?>
<?php if ($tpl['formShow']) : ?>
<!-- Formular ausgeben -->
<?php endif; ?>
<?php include('footer.php'); ?>Das Entscheidende ist dieser „Cut“, der eine Schnittstelle zwischen Verarbeitung und Ausgabe darstellt, indem alle relevanten Daten übergeben werden. Wie die Schnittstelle im Endeffekt umgesetzt wird, ist egal. Das kann auch ein Funktionsaufruf renderTemplate($templateFile, $vars);, eine Template-Engine oder was auch immer sein.
