Problem bei eienr IF Abfrage (isset($a->name) ? if($a->name==1)'

[andi]

Ich habe ein Problem das ich leider nicht lösen kann. Ich lese aus meiner Datenbank aus, und die Ergebnisse möchte ich dann in einer Tabele ausgeben. Damit auch alle Felder vorhanden sind, mach ich das so:

<td>'.(isset($a->name) ? '<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

Ich möchte aber innerhalb dieser Prozdur noch eine Abfrage machen, ob ein bestimmter Wert vorhanden ist, doch hier geht es nicht weiter und ich bekomme folgende Fehlermeldung

Parse error: syntax error, unexpected 'if' (T_IF) in

<td>'.(isset($a->name) ? if($a->name==1)'<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

[dedlfix]

Tach!

Parse error: syntax error, unexpected 'if' (T_IF) in

<td>'.(isset($a->name) ? if($a->name==1)'<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

if ist eine Anweisung und kein Operator. Das kann nicht in einem zu berechnenden Ausdruck verwendet werden. Lediglich der ?:-Operator kann da für Bedingungen Anwendung finden - auch verschachtelt, wobei man dann Klammern setzen sollte, damit klar ist, was zu wem gehört.

dedlfix.

[Auge]

Hallo

Ich möchte … innerhalb dieser Prozdur noch eine Abfrage machen, ob ein bestimmter Wert vorhanden ist, doch hier geht es nicht weiter und ich bekomme folgende Fehlermeldung

Parse error: syntax error, unexpected 'if' (T_IF) in

<td>'.(isset($a->name) ? if($a->name==1)'<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

Du willst also erst prüfen, ob $a->name existiert und dann, ob es den Wert 1 hat. Für eine der Bedingunen fehlt aber der Else-Zweig. Der muss bei einem ternären Operator für jede der gestellten Bedingungen vorhanden sein.

Prüfung, ob $a->name existiert, Speicherung in einer Variable statt der Ausgabe:

<?php $var = isset($a->name) ? true : false; ?>

Im Fall true soll nun weiterhin nach dem Wert unterschieden werden.

<?php $var = ($a->name == 1) ? 'ja' : 'nein'; ?>

Nun mit den Klammern die Schachtelung der Anweisungen klarstellen:

<?php $var = isset($a->name) ? (($a->name == 1) ? 'ja' : 'nein') : false; ?>

Tschö, Auge

[Jörg Reinholz]

Moin!

mach ich das so:

<td>'.(isset($a->name) ? '<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

Das wirft die Frage auf, wie es sein kann, dass a->name nicht existiert. Wäre nicht empty() die bessere Wahl?

Ich möchte aber innerhalb dieser Prozdur noch eine Abfrage machen, ob ein bestimmter Wert vorhanden ist, doch hier geht es nicht weiter und ich bekomme folgende Fehlermeldung

Parse error: syntax error, unexpected 'if' (T_IF) in

<td>'.(isset($a->name) ? if($a->name==1)'<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

So macht man es sich selbst schwer.

$foo='<td>';
if ( ! empty($a['name']) && $a['name'] == 1 ) {
   $foo .= '<img src="yes.png" alt="Ja">'
} else {
   $foo .= '<img src="no.png" alt="Nein">' 
}
$foo .= '</td>';

… ist viel besser lesbar und ergo weniger fehlerträchtig. Mir scheint zudem, dass im vorgestellten Fall die Information im alt-Attribut angezeigt werden sollte, z.B. falls jemand Grafiken nicht anzeigen lässt.

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

So macht man es sich selbst schwer.

$foo='<td>';
if ( ! empty($a['name']) && $a['name'] == 1 ) {
   $foo .= '<img src="yes.png" alt="Ja">'
} else {
   $foo .= '<img src="no.png" alt="Nein">' 
}
$foo .= '</td>';

… ist viel besser lesbar und ergo weniger fehlerträchtig.

Besser ja, aber nicht gut. So macht man es sich selbst schwer.

<td>
  <?php if ( ! empty($a['name']) && $a['name'] == 1 ): ?>
    <img src="yes.png" alt="Ja">
  <?php else: ?>
    <img src="no.png" alt="Nein">
  <?php endif; ?>
</td>

… ist viel besser lesbar und ergo weniger fehlerträchtig.

Mir scheint zudem, dass im vorgestellten Fall die Information im alt-Attribut angezeigt werden sollte, z.B. falls jemand Grafiken nicht anzeigen lässt.

Oder nicht sehen kann.

Gemäß RFC 2119 muss es hier muss heißen, nicht sollte.

LLAP 🖖

[Jörg Reinholz]

Moin!

Ich weiß ja nicht, was Dich reitet, aber dem vom TO dargestellten Quelltext nach baut er sich wohl mindestens die Tabellenzelle zusammen, wahrscheinlich die ganze Zeile, womöglich eine ganze Tabelle. Wir wissen nicht warum.

Es ist vorliegend jedenfalls so, dass Deine andere Idee nicht die unter allen Umständen einzig richtige ist.

Mir scheint zudem, dass im vorgestellten Fall die Information im alt-Attribut angezeigt werden sollte, z.B. falls jemand Grafiken nicht anzeigen lässt.

Oder nicht sehen kann.

Gemäß RFC 2119 muss es hier muss heißen, nicht sollte.

Das ist vorliegend sogar falsch.

Gemäß dem W3C ist es nicht in jedem Fall notwendig, einen (nichtleeren) alternativen Text hinzuzufügen.

Da ich den Kontext nicht kenne ist es gemäß RFC 2119 also durchaus richtig, hier "sollte" zu schreiben.

Falls es jemand ganz genau formulieren will: "Es erscheint mir so als muss …"

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

Es ist vorliegend jedenfalls so, dass Deine andere Idee nicht die unter allen Umständen einzig richtige ist.

Mir ist noch kein Umstand begegnet, wo die Zusammenstückelung des HTML-Quelltextes mit PHP sinnvoll wäre. Ein solcher Umstand würde auf falsche™ Softwarearchitektur hindeuten – die nichtvollzogene Trennung von Logik und Ausgabe.

Mir scheint zudem, dass im vorgestellten Fall die Information im alt-Attribut angezeigt werden sollte, z.B. falls jemand Grafiken nicht anzeigen lässt.

Gemäß RFC 2119 muss es hier muss heißen, nicht sollte.

Gemäß dem W3C ist es nicht in jedem Fall notwendig, einen (nichtleeren) alternativen Text hinzuzufügen.

Finde den Fehler! Um es dir leichter zu machen, habe ich mal ein paar Stellen hervorgehoben.

LLAP 🖖

[Jörg Reinholz]

Moin!

Finde den Fehler! Um es dir leichter zu machen, habe ich mal ein paar Stellen hervorgehoben.

hier

Dafür, um aus dem irgendwas sicher zu schließen ist der im Ausgangsposting gebotene Stoff zu dünn. Und wenn es keine Gewissheit gibt, dann sind wir beim "Meinen", ergo beim "sollte" in Sinne von "Es erscheint mir so als muss …" und nicht beim "muss".

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

hier

Dafür, um aus dem irgendwas sicher zu schließen ist der im Ausgangsposting gebotene Stoff zu dünn.

Das Eis trägt.

Es geht darum, dem Nutzer den Wert von isset($a->name) && $a->name === 1 darzustellen. Damit das für alle Nutzer passiert, sind Alternativtexte für die Grafiken in diesem Fall ein Muss.

LLAP 🖖

[Jörg Reinholz]

Moin!

Es geht darum, dem Nutzer den Wert von isset($a->name) && $a->name === 1 darzustellen. Damit das für alle Nutzer passiert, sind Alternativtexte für die Grafiken in diesem Fall ein Muss.

Und woher willst Du wissen, dass es sich nicht um bloßes "optisches Beiwerk", vielleicht sogar eine doppelt dargestellte Information ohne jeden zusätzlichen Informationsgehalt handelt, welche die Mühen einer Textausgabe durch Anzeigen als Braille-Schrift oder des Vorlesens nicht wert ist?

Also: "Vorsicht mit den jungen Kühen!" -> "sollte"

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

Und woher willst Du wissen, dass es sich nicht um bloßes "optisches Beiwerk", vielleicht sogar eine doppelt dargestellte Information ohne jeden zusätzlichen Informationsgehalt handelt

Weil der Theo dann gefragt hätte, warum die if-Abfrage an der für alle Nutzer relevanten Stelle nicht funktioniert. ;-b

LLAP 🖖

[Jörg Reinholz]

Moin!

@@Jörg Reinholz

Und woher willst Du wissen, dass es sich nicht um bloßes "optisches Beiwerk", vielleicht sogar eine doppelt dargestellte Information ohne jeden zusätzlichen Informationsgehalt handelt

Weil der Theo dann gefragt hätte, warum die if-Abfrage an der für alle Nutzer relevanten Stelle nicht funktioniert. ;-b

Nein, er hat keinerlei Informationen über die Umstände gegeben. Also haben wir diese Information nicht. Es ist also pure Spekulation hier anzunehmen, dass die Ausgabe des Alternativtextes notwendig oder auch nur angebracht ist und damit ist es eine (von vielen nicht als "wertschätzend" verstandene) Bevormundung, wenn ihm hier ein MUSS "um die Ohren gehauen" wird.

Jörg Reinholz

[1unitedpower]

<td>'.(isset($a->name) ? if($a->name==1)'<img src="yes.png" alt="">' : '<img src="no.png" alt="">').'</td>

So macht man es sich selbst schwer.

<?php
$foo='<td>';
if ( ! empty($a['name']) && $a['name'] == 1 ) {
   $foo .= '<img src="yes.png" alt="Ja">'
} else {
   $foo .= '<img src="no.png" alt="Nein">' 
}
$foo .= '</td>';

… ist viel besser lesbar und ergo weniger fehlerträchtig.

Über Lesbarkeit kann man streiten, if-Statements haben sprechende Keywords, die die einzelnen Bestandteile identifzieren, Ternitäts-Opertoren sind dafür weniger verbose.

Fehlerträchtiger ist ganz objektiv betrachtet allerdings die if-Variante. Der elementare Unterschied ist ja, dass es sich beim Ternitäts-Operator um einen Ausdruck handelt und beim if-Konstrukt um ein Kommando. Ausdrücke nehmen Eingaben entgegen und produzieren daraus Werte. Bei der Wahl ihrer Eingaben sind Ausdrücke sehr restriktiv, dort sind wiederum nur Ausdrücke erlaubt, keine Kommandos. Im Beispiel des TOs hat ja gerade dieses Verhalten zu einem Syntaxfehler geführt. Das ist eine gute Sache, denn das frühtzeitge Aufspüren von Fehlern ist eine wichtige Waffe gegen Fehleranfälligkeit. Kommandos hingegn erzeugen keine Werte, sie nehmen Einfluss auf den Programmablauf, indem sie den Speicherzustand manipulieren. Das ist vermutlich die häufigste Ursache für Programmfehler überhaupt, und zwar von der richtig üblen Sorte, weil man diese Fehler im Allgemeinen erst zur Laufzeit aufspüren kann.

Ausdrücke haben ferner den Vorteil, dass man ihren Rückgabewerten Namen geben kann, das fördert Lesbarkeit und sorgt gleichzeitig für erhöhte Wiederverwendtbarkeit.

<?php
list($imgSrc, $imgAlt) = (isset($a->name) && $a->name === 1)
  ? ['yes.png', 'Ja']
  : ['no.png', 'Nein'];

$td = "<td><img src=\"$imgSrc\" alt=\"$imgAlt\"></td>";

Bzw. in eingebetteter Schreibweise:

<?php
list($imgSrc, $imgAlt) = (isset($a->name) && $a->name === 1)
  ? ['yes.png', 'Ja']
  : ['no.png', 'Nein'];
?>
...
<td><img src="<?= $imgSrc ?>" alt="<?= $imgAlt ?>"></td>

Gunnars Vorschlag ist ein Spezialfall eines if-Statements, das ohne interne Speichermanipulation auskommt, weil die then- und else-Blöcke implizit an einer String-Konkatenation teilnehmen. Dieses Konstrukt ist semantisch dem Ternitäts-Operator sehr viel ähnlicher als der hier zuerst vorgeschlagenen if-Variante. Der Unterschied zu meinem Vorschlag ist hauptsächlich der Zeitpunkt an dem die Logik stattfindet: Im weitesten Sinne wäre das bei Gunnar im View, bei mir im ViewModel. Darüber wiederum gibt es eine ganz eiegene hitzige Debatte.

[Gunnar Bittersmann]

@@1unitedpower

Der Unterschied zu meinem Vorschlag ist hauptsächlich der Zeitpunkt an dem die Logik stattfindet: Im weitesten Sinne wäre das bei Gunnar im View, bei mir im ViewModel. Darüber wiederum gibt es eine ganz eiegene hitzige Debatte.

Mir ging es hier nur darum, den bestehenden Code für die View umzuschreiben. Dass die Fallabfrage gar nicht in der View erfolgen sollte, sondern schon früher, keine Frage. Deine zweite(!) von dir gezeigte Variante ist vielleicht die, wie man’s machen sollte.

Es sei denn:

<?php
$available = (isset($a->name) && $a->name === 1);

<td>
  <?php if ( $available ): ?>
    <img src="yes.png" alt="Ja">
  <?php else: ?>
    <img src="no.png" alt="Nein">
  <?php endif; ?>
</td>

"yes.png", "no.png", "Ja" und "Nein" haben nicht wirklich was in der Programmlogik zu suchen.

LLAP 🖖

[1unitedpower]

"yes.png", "no.png", "Ja" und "Nein" haben nicht wirklich was in der Programmlogik zu suchen.

Das ist schwierig zu entscheiden. Wir sind uns mit Sicherheit einig, dass es nicht Teil der Geschäftslogik sondern vielmehr Teil der Ausgabelogik ist. Wohin letztere gehört, ist ein viel umstrittenes Thema. Eine Möglichkeit ist, die Ausgabelogik als Teil des Views zu betrachten. Klassisches PHP-Templating, wie du es hier anwendest, folgt diesem Ansatz. Dem gegenüber liegt das Extrem, den View vollständig frei von Logik zu halten. Bei diesem Ansatz entkoppelt man den View von der Ausgabelogik, und lagert letztere typischerweise in sogenannte ViewModel und ViewHelper aus. Die Mustache-Templating-Engine ist ein bekannter Vertreter dieser Philosophie. Und dann gibt es hybride Ansätze, bei denen häufig wiederkehrende Ausgabelogik in ViewModel und -Helper fließt, spezialisierte Ausgabelogik aber im View verbleibt. Sathish Pottavathini hat diesen letzten Ansatz sehr gut begründet.