QFQ

Vorschlag

• Idee: QFQ Records koennen an beliebiger Stelle in REPORT eingebunden werden. Bsp.
  

  10 {
    sql = SELECT ...
    20.sql = SELECT ...
    30.uid = 123|accountId,feUserUid
    40.uid = 124|*
  }
  
  # Alternative um die `uid` lesbarer zu machen: Die Spalte tt_content.sub_header wird im T3 Backend 
  #    bei QFQ Records editierbar gemacht und es kann ein 'Funktionsname' gesetzt werden:
  # Sollten mehrere tt_content records den gleichen Funktionsnamen haben, zeigt QFQ einen Fehler an.
  
  50.uid = userLogin|feUserUid,accountId
  
  60.uid = getPeriod|*|skip cache
  

• Die Variablennamen hinter dem uid/Funktionsname gibt an, was durch die Funktion via STORE_RECORD exportiert wird. Damit ist klar welche Parameter zurueck kommen.
• Diskussion: sollten auch die aufrufenden Parameter deklariert werden?
• Der '*': alles was in der Funktion in den STORE_RECORD kopiert.
• STORE_USER ist immer schreib/lesbar.
• cache = 30 - Der STORE_RECORD der Funktion wird gecacht und der tt_content Record maximal alle 30 Sekunden gefeuert. Ein erneuter Aufruf innerhalb der Cache time liefert den Cache.
• cacheUser = 5 - wie Cache, aber pro User Session, 5 Sekunden.
• 'skip cache' - Die Query wird immer ausgefuehrt, unabhaengig ob eine Cache Time definiert ist.

• Beispiel: tt_content.uid = 123
  

  cache = 30
  10.sql = SELECT 1 AS accountId, 2 AS feUserUid
  

Ist insgesamt viel mehr als ich eigentlich brauche, aber warum nicht?

• Ich würde auch aufrufende Parameter ermöglichen. In meinen Beispielen bräuchte ich das zwar nicht, kann ich mir aber gut vorstellen, dass das gebraucht würde. Z.B. mit ähnlicher Schreibweise wie bei den Excel Exports: 10.uid = 123&isProf=1|feUserId,accountId
• Falls QFQ-Record-Funktionsnamen umgesetzt werden - gerne auch für die Excel-Exporte verwenden
• Cache: falls auch für andere QFQ-Records verwendet, müsste man natürlich auch die Ausgabe des Records cachen, nicht nur STORE_RECORD.
  • Den Cache brauchts aus meiner Sicht nicht zwingend. Wenn eine Seite geladen wird, möchte ich eigentlich in den meisten Fällen sicher sein, dass die Daten aktuell sind, nicht 30s alt. Die Variablen würden so oder so nur einmal pro Page Load berechnet und stünden dann beliebig oft zur Verfügung im nachfolgenden Code.
• uid: mögliche andere Namen: 10.load oder 10.import

Check ob man #8450 damit loesen koennte?!

Naming:

10.function = getFeUser(pId, pName) => accountId, feUserUid

• function ist klarer als uid
• Beispiel: getFeUser ist der subheader Name des aufzurufenden tt-content records. Wird eine reine Zahl angegeben, ist die uid gemeint. Bsp 10.function = 123.
• Sind neben .function noch weitere Token wie sql, head, ... angegeben: function wird als erstes ausgefuehrt, danach wie gewohnt alles andere.
• Ist nur function definiert, aber kein sql werden keine Sublevel gefeuert.
• Die runden Klammern mit (pId, pName) entsprechen der bekannten Notation eines Funktionsaufrufes.
• Die Returnwerte werden durch '=>' angezeigt.
• Die Funktion sollte so implementiert werden das aus dem STORE_RECORD nur die definierten Variablen verwendet werden koennen.
• Die Aufrufparameter und die Returnparameter werden im STORE_RECORD uebergeben.
• Der STORE_RECORD wird nicht veraendert (ausser den definierten Returnwerten).
• Der Output der in der Funktion erzeugt wird (optional) kann abgerufen werden via {{_output:R}}
• Ein Cache wird erstmal nicht implementiert.
• Optional koennte man auch ueber die Verwendung des STORE_PARENT nachdenken.

• Koennen in einer Function weitere Functions aufgerufen werden?

Das tönt echt gut.

Hier noch ein anderer Notationsvorschlag:

10.function = getFeUser(pId, pName) => accountId, feUserUid

• Funktion speichert etwas in der DB, ohne Return value
• Funktion speichert etwas oder mehrere Werte auf einmal im U-Store (Bsp. feUserId, acctId, isDev, isProf, isSecretary, ...), diese sind dann sozusagen der globale Return value, aber ohne eigentlichen Return value der Funktion im R-Store

• Wäre schon brauchbar.
• Wenn kompliziert, dann "vorerst" darauf verzichten?
• Das Aufrufen von einzelnen Funktionen ist an sich schon ein riesiger Sprung vorwärts.

Aktuell haben wir bei diversen Tools, bei denen PDFs & Attachments zu einem PDF zusammengefuehrt werden und diese Full-PDF Links auf diversen Seiten benoetigt werden, eine Zwischenseite eingebaut. Damit war die PDF Definition nur an einer Stelle, und man konnte im gesamten Tool Links auf diese Zwischenseite bauen.

Der Nachteil: die User mussten immer zweimal klicken um an ein PDF zu gelangen.

Neu soll als weitere Download Source (neben 'F,p,u,uid') auch source:<qfq function>&arg1=value1$arg2=... moeglich sein.

In <qfq function> werden dann die ueblichen Sourcen ausgegeben in der Form 'F:file1.pdf|p:myBaseData&appId=123|F:file2.pdf'. Dabei ist es egal aus wieviel Spalten/Rows, es wird alles implodiert und muss ein (multiple) Sources Argument ergeben.