QFQ

Das rendern (zusammensetzen aus mehreren Quellen) eines PDF kann lange dauern. Vorschlag fuer ein Caching:

• Es gibt ein Cache Verzeichniss, fileadmin/protected/cache.

• Beim zusammenbauen (Parameter in _link) kann neu ein Caching Token bestehend aus 'tablename/id/column'-Tripples (falls kein 'columnname' angegeben ist, wird 'modified' genommen ) angegeben werden.

Cache Verzeichnis (konfigierbar in QFQ) fileadmin/protected/cache/

... AS _pdf (AS _link)   d|p:header&r=567|f:fileadmin/protected/file1.pdf|f:fileadmin/protected/file2.pdf|cache=[<tablename>/<id>[/column]][,...]      >> md5=34857sdjk4387564387y 
                                                                                         fileadmin/protected/cache/34857sdjk4387564387y.pdf   (modified datum)
... AS _savePdf schreibt in den Cache
... AS _saveZip schreibt in den Cache

f: AS _zip

EN: Beispiel Syntax- 10.sql = SELECT CONCAT AS _link
Zusammengesetzten PDF ins cache Ordner ablegen falls noch nicht existent. Von dort wird der Download ausgeführt (Bisherige Funktion führt keinen Download aus, sondern öffnet PDF im Browser). Das im Cache abgelegte File wird bei nochmaligem Aufruf mithilfe vom Check des MD5 Hashes überprüft auf veränderten Inhalt, falls ja: Das File im Cache mit dem neu zusammengesetzten PDF ersetzen und (Download ausführen) PDF öffnen.

Für die Identifikation des richtigen Files im Cache wird der Filename verwendet ('d:MergedPdf'. Muss in dem Fall angegeben werden, da ansonsten kein Abgleich möglich. Als Default wird immer output.pdf ausgegeben.)
Ein Check auf den Erstellungsdatum des Files im Cache wäre überflüssig, da bei Änderungen das File sowieso erneut erzeugt werden muss.

Infos:
MD5 Hash check for changes: https://www.w3schools.com/php/func_string_md5_file.asp
Check auf Erstellungsdatum, stündlich (eigentlich überflüssig, da bei Änderung immer File ersetzt werden muss): if (time() - filemtime("test.pdf") > 60*60*1){unlink("test.pdf");}

• Von allen Source Reference Angaben (filename, url) wird ein MD5 Hash gebaut. In dem Hash ist kein Timestamp enthalten, denn dann wuerde die zuletzt gecachte Datei nicht ueberschrieben werden bei einem Update.
  EN: Ich konnte nirgends finden dass ein Timestamp im MD5 Hash möglich ist.

• Unter dem <cache Verzeichnis>/<MD5> wird die fertig gerenderte Datei gespeichert.
  EN: Für was steht <MD5>? Das zusammengesetzte PDF File oder nur ein abgelegter Hash?

• Von allen Filename wird der 'modified'-Timestamp, und die Timestamps der aufgeloesten 'tablename/id/column'-Tripple, verglichen mit dem modified timestamp der Datei '<cache Verzeichnis>/<MD5>'
  EN: Nicht mehr benötigt in unserem Fall? Lösung sollte ohne DB Eintrag möglich sein soweit ich das verstanden habe.

• Gibt es min. einen Timestamp der neuer ist als der der gerenderten Datei, wird die Datei neu gebaut.
  EN: Gleiche Aussage wie beim letzten Punkt? Timestamp nicht mehr nötig da kein DB Eintrag.

• Es gibt ein Token im Link, welches beim rendern dazu fuehrt das das PDF auf Vorrat (im Cache Verzeichnis) gebaut wird.
• Das Render passiert am besten asynchron, gesteuert ueber rabittmq oder mqtt (#5851)

EN: Allgemein zum Cache Feature: Hat nichts direkt mit dem Zip zu tun oder? Welches ja angefragt wurde für Medtool. Eine Anwendung vom Mode: Zip mit _link kann eine aneinanderreihung von PDF Files als ein Zip herausgeben. Dieser wird als Dowload angeboten. Besser: Etwas wie _saveZip könnte einmal Stündlich mit Autocron ausgeführt werden um einen abgelegten Zip File zu refreshen. Der Zusammenhang mit dem Caching wäre hilfreich wenn wir dies direkt über _link ermöglichen wollen, da viele PDFs gemerged werden müssen (ca. 30 bis 40). Wäre es da nicht schlauer mit einem Autocron und per neuem _saveZip diese abzuspeichern und nicht direkt per Download über _link anzubieten?