Project

General

Profile

Feature #11998

Custom QFQ-Function

Added by Elias Villiger 7 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
11.02.2021
Due date:
% Done:

0%

Estimated time:
Discuss:

Description

Einige Ids werden auf verschiedensten Seiten jedesmal neu berechnet. Das bedeutet 1) Code duplication und 2) ev. Performance-Einbusse

Beispiel: die person.id des eingeloggten Users:

SELECT pId FROM account WHERE accountType='uzh shortname' AND username='{{feUser:UTE}}'

oder die geoleanAccess property ids für die aktuelle feUserGroups:
SELECT GROUP_CONCAT(id) FROM gGroup WHERE name='geoleanAccess' AND gType='property' AND t1 IN({{feUserGroup:UT0}})

Wichtig: Zugriff auf den Typo3-Store.

Die Variabeln für meine Anwendungen müssten nur selten aktualisiert werden. Einmal pro Page Load oder allenfalls pro Session würde reichen.

Mögliche Lösungen:
  • Bereits jetzt möglich: Die gewünschten Variabeln über QFQ im User-Store definieren, z.B. auf der Seite nach dem Login, oder über Einbinden eines QFQ-Records auf allen Seiten mittels template:
      // Einbinden des Records mit uid:96 auf allen Seiten
      page.200 = RECORDS
      page.200 {
        tables = tt_content
        source = 96
      }
    
  • Neue Option, Custom QFQ-Code zu definieren. In Konfig, dynamisch gerendert? In tt_content Record?

Related issues

Related to QFQ - Feature #11569: Custom QFQ-Code pro SessionClosedCarsten Rose21.11.2020

Actions
Has duplicate QFQ - Feature #7883: Link to QFQ record: '... AS _qfq'RejectedCarsten Rose14.02.2019

Actions
Has duplicate QFQ - Feature #10713: QFQ functions (reusable reports)RejectedMarc Egger04.06.2020

Actions
#1

Updated by Elias Villiger 7 months ago

#2

Updated by Carsten Rose 7 months ago

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
    
#3

Updated by Elias Villiger 7 months ago

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

Einige Kommentare/Fragen:
  • 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
#5

Updated by Philipp Gröbelbauer 7 months ago

Check ob man #8450 damit loesen koennte?!

#6

Updated by Carsten Rose 6 months ago

  • Subject changed from Custom QFQ-Code zentral definiert to Custom QFQ-Function
#7

Updated by Carsten Rose 6 months ago

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.
Frage:
  • Koennen in einer Function weitere Functions aufgerufen werden?
#8

Updated by Elias Villiger 6 months ago

Das tönt echt gut.

Hier noch ein anderer Notationsvorschlag:

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

Wichtig wäre mir, dass es auch Funktionen ohne Return-Wert geben kann. Gebrauch z.B.:
  • 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
Koennen in einer Function weitere Functions aufgerufen werden?
  • Wäre schon brauchbar.
  • Wenn kompliziert, dann "vorerst" darauf verzichten?
  • Das Aufrufen von einzelnen Funktionen ist an sich schon ein riesiger Sprung vorwärts.
#9

Updated by Carsten Rose 6 months ago

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.

#10

Updated by Carsten Rose 6 months ago

  • Status changed from New to Closed
#11

Updated by Carsten Rose 6 months ago

  • Related to Feature #7883: Link to QFQ record: '... AS _qfq' added
#13

Updated by Carsten Rose 6 months ago

  • Related to deleted (Feature #7883: Link to QFQ record: '... AS _qfq')
#14

Updated by Carsten Rose 6 months ago

  • Has duplicate Feature #7883: Link to QFQ record: '... AS _qfq' added
#15

Updated by Carsten Rose 6 months ago

  • Target version changed from 21.8.0 to 21.3.1
#16

Updated by Marc Egger 13 days ago

  • Has duplicate Feature #10713: QFQ functions (reusable reports) added

Also available in: Atom PDF