@@pl
Sie trägt jedoch zum Verständnis bei, weil: Platzhalter in einem Template brauchen Namen. Ergo ist obenstehende Datenstruktur für eine TE ungeeignet, weil die Werte keine Namen haben.
Ja.
Es gibt tatsächlich TE's die mit namenlosen Platzhaltern arbeiten wie z.B.:
sprintf("Name: %s\nVorname: %s", $name, $vname);
Von daher brauchen wir ein Objekt für jede Zeile und wenn es mehrere Zeilen werden sollen, ein Array mit Objekten.
Nein.
Freilich würde es auch mit anderen Datenstrukturen funktionieren, bspw. würde es auch ein einfaches Array tun. Aber wie gesagt, es hängt von den verfügbaren TE's ab wie die Datenstruktur aussehen muss. Die TE Mustache die ich hier namentlich genannt hatte, braucht ein Array mit Objekten:
[
{
Name => $name,
Vorname => $vname,
Ort => $ort
}, # 1. Zeile
{usw.}, # 2. Zeile usw
]
Und so heißen die Platzhalter in jeder <td>{{Name}}</td>
so wie die Schlüssel in obenstehender Datenstruktur. Alle TE's die ich kenne, funktionieren auf diese Art und Weise und auch die beiden TE's die ich für Perl bzw, JavaScript selbst entwickelt habe funktionieren mit denselben Datenstrukturen.
Des Weiteren ist es in Perl wie auch in PHP möglich, SQL-Ergebnismengen auf solch eine Datenstruktur -- Array mit Hashreferenzen/Array mit Objekten -- zu lesen (Slice-Option in Perl) und damit unmittelbar eine TE zu füttern. Dabei ist es unerheblich, ob dazwischen ein Transport-Layer eingeschaltet ist, genau dieser wird in dem Augenblick transparent, wenn alle TE's mit denselben Datenstrukturen zurechtkommen.
Vielleicht verstehst Du ja jetzt, dass die Frage der Datenstruktur nicht etwa eine Frage der Willkür ist sondern eine Frage der Zweckmäßigkeit. Eher nebensächlich hingegen ist die Frage der Verpackung für den Transport; das kann ein beliebiger Serializer erledigen und so ist JSON nur eine von vielen Möglichkeiten.
Ebenso ist es abstrakt gesehen auch egal, auf welchem Wege die Daten in die Anwendung kommt, File-API, Ajax-Response oder über Santa Claus ;)