QFQ

• Die einzelnen Felder (row.firstname, row.name, row.link|qfqlink, ...) müssten pro Template jeweils einzeln aufgelistet werden (? - jedenfalls im Fall von speziellen Spalten wie AS _link)
• Spezielle Spalten wie _Pagee oder versteckte Spalten AS _hidden müssten vermutlich auch einzeln gehandhabt werden (wie qfqLink für AS _link) - je nach angebotener Funktionalität könnte das schnell kompliziert werden.

Die Idee des Templatings finde ich aber sehr attraktiv, da man so einiges an repetitivem Tippen einsparen könnte. Mein Vorschlag wäre, ein QFQ-eigenes Templating anzubieten:

10 {
  sql = SELECT * FROM person
  template = fileadmin/qfqTemplates/standardTable
}

Der User kann dann entsprechende Templates abspeichern, welche in QFQ-Notation gehalten sind, z.B.

head = <table class="table">
tail = </table>
rbeg = <tr>
rend = </tr>
fbeg = <td>
fend = </td>

Bequem wäre auch, wenn man einzelne Felder des Templates überschreiben könnte (Template wird zuerst eingelesen, dann mit zusätzlichen angegebenen Feldern überschrieben):

20 {
  sql = SELECT * FROM person
  template = fileadmin/qfqTemplates/standardTable
  head = <table class="table table-condensed"><tr><th>Id</th><th>Name</th><th>E-Mail</th></tr>
}

Bei Gebrauch von Twig würde ev. die Generalisierung von QFQ etwas verloren gehen [...]

Korrekt. Aber das ist ja auch ein Stück weit die Idee. Ziel von Template-Engines ist üblicherweise Darstellung von Datenzugriff zu trennen. (d.h. das SQL-Query sollte keine Info zur Darstellung enthalten)

(Aber es wäre natürlich nicht besonders schwierig Templates zu erstellen, die die Darstellung vom Spaltennamen abhängig machen.)

Mein Vorschlag wäre, ein QFQ-eigenes Templating anzubieten

Davon würde ich dringend abraten. Wenn immer möglich sollten wir auf bestehende und etablierte Tools zurückgreifen. (und im Dekanat werden definitiv weiter mit Twig arbeiten, das hat sich bei uns bereits sehr bewährt. Nötigenfalls werden wir das also auch weiterhin selbst reinpatchen)
Falls du konkrete, komplexere Template-Beispiele möchtest, einfach melden.

Bequem wäre auch, wenn man einzelne Felder des Templates überschreiben könnte

Twig bietet die Möglichkeit aus einem Template andere Teil-Templates zu laden. Das ist aber in meinem QFQ-Code noch nicht richtig integriert.

Macht Sinn. Ich dachte, es ginge vor allem darum, den Boilerplate von head/tail/rbeg/... zu reduzieren, aber wenn es um eine Trennung von Design und SQL-Code geht, macht Twig schon Sinn.

Das oben beschriebene "QFQ-eigene Templating" wäre auch nicht wirklich ein "Templating" in dem Sinne, sondern eher ein Auslagern häufiger Darstellungsoptionen zur Wiederverwendung.

Für eigenen meinen Gebrauch von QFQ (geolean) sehe ich keine grossen Anwendungen für Templating im Sinn von Twig; aber da es sich bei euch bewährt, würde mir ein Einblick in euren Umgang damit bestimmt weitere Perspektiven zeigen.

Ich habe das Ticket jetzt wieder Carsten zugewiesen, dann können wir nach seinen Ferien weiterschauen.