Project

General

Profile

Feature #10713

QFQ functions (reusable reports)

Added by Marc Egger 5 months ago. Updated 4 months ago.

Status:
Priorize
Priority:
Normal
Assignee:
Target version:
Start date:
04.06.2020
Due date:
% Done:

0%

Estimated time:
Discuss:

Description

Prio2 für Nicola

QFQ Report code als Funktion verpacken mit parameter. Diese Funktion kann dann in anderern Reports benutzt werden.

Ist nahe an dem QFQ patterns Vorschlag von Benj: #10345

Angefragt durch Nicola. Use Cases Nicola:  use-cases_conditions-functions.txt

Gedanken von Nicola zum Thema:

*) Ich denke auch, dass wir vermeiden sollten QFQ zu stark auszubauen. Für
mich wäre es also auch ok, wenn wir zur Einsicht kommen, dass wir Student
Admin auf eine andere Lösung migrieren müssen. (Wäre eine spannende Frage, wie
das möglichst weitgehend automatisiert werden kann. :-)
  *) Die Idee, volle PHP-Funktionen einzubinden finde ich ziemlich
vielversprechend. Damit könnte die Komplexität von QFQ selbst hoffentlich tief
gehalten werden. Wichtig wäre aber sicher, dass in diesen Funktionen effizient
QFQ-Funktionalität genutzt werden kann (z.B. den QFQ-Mailer aufrufen oder die
QFQ-DB-Verbindung nutzen.)


Related issues

Related to QFQ - Support #10345: Templates - Patterns QFQ StyleNew2020-04-02

Related to QFQ - Feature #10716: Business Logic mit Externen SkriptenPriorize2020-06-04

History

#1 Updated by Marc Egger 5 months ago

#2 Updated by Marc Egger 5 months ago

  • Description updated (diff)

#3 Updated by Marc Egger 5 months ago

  • Status changed from New to Priorize

#4 Updated by Marc Egger 5 months ago

  • Tracker changed from Support to Feature

#5 Updated by Marc Egger 5 months ago

  • Description updated (diff)

#6 Updated by Marc Egger 5 months ago

  • Related to Feature #10716: Business Logic mit Externen Skripten added

#7 Updated by Marc Egger 4 months ago

QFQ funktionen/reusable-reports Pro/Contra

Pro:
- weniger redundanz
- anpassungen nur an einem ort machen

Contra:
- zusätzliche QFQ Syntax
- Reports werden komplexer, zur Zeit ist jeder Report eine abgeschlossene Komponente für sich
- Funktionen verleiten dazu, general purpose code zu schreiben, der sehr viele conditionals hat. ala: "ich könnte hier eine Funktion schreiben die möglichst allgemein ist und alles abdeckt"

Grundsätzlich sehe ich grosse Vorteile von Funktionen/reusable-reports für Maintainer, die ein QFQ Projekt schon in und auswendig kennen. Aus eigener Erfahrung sehe ich für eine Person, die neu zu einem bestehenden Projekt kommt, eher Nachteile. Zur Zeit ist es für mich möglich, an einem mir fremden Tool eine Änderung zu machen, ohne Angst zu haben, dass dies unerwartete Konsequenzen hat. Wenn beispielsweie eine SQL Anfrage auf einem Report angepasst werden muss, dann kann ich diesen Report verstehen, ihn anpassen und den Report anschauen. Damit habe ich schon den grossteil aller Testszenarien abgedeckt. Wenn wir ein stabiles und wartbares QFQ Tool haben möchten mit Funktionen/Reusable-reports, dann müssen wir meiner Meinung nach auch unittests einführen, um diese Funktionen/reusable-reports zu Testen und ihr Verhalten zu definieren.

Um die Übersicht zu erleichtern, könnten wir die Funktionalität etwas einschränken.
Beispielsweise müsste jeder reusable-report in einem eigenen File sein, das in dem Ordner "reusable-reports" abgelegt ist.
Jdes reusable-report-file hat dann folgende Struktur:

- funktionsname
- funktionsargumente
- funktionsoutput (?)
- unittests
- funktion body

#8 Updated by Nicola Chiapolini 4 months ago

Grundsätzlich sehe ich grosse Vorteile von Funktionen/reusable-reports für Maintainer, die ein QFQ Projekt schon in und auswendig kennen. Aus eigener Erfahrung sehe ich für eine Person, die neu zu einem bestehenden Projekt kommt, eher Nachteile. Zur Zeit ist es für mich möglich, an einem mir fremden Tool eine Änderung zu machen, ohne Angst zu haben, dass dies unerwartete Konsequenzen hat. [...]

Ich bin völlig einverstanden, dass mit schlecht definierten Funktionen der Einstieg schwieriger werden kann - aber das kann kein Argument sein um Code-Duplication zu fördern. Es macht aber sicher Sinn, wenn wir uns überlegen, wie wir schlechte Funktionen verhindern und was den Einstieg vereinfachen könnte (z.B. einen Report, der alle Referenzen zu einer Funktion zusammenträgt).

Wenn wir ein stabiles und wartbares QFQ Tool haben möchten mit Funktionen/Reusable-reports, dann müssen wir meiner Meinung nach auch unittests einführen,

Ein stabile, wartbares Projekt braucht bereits jetzt Tests. Denn ohne Funktionen sind die Chancen viel zu gross, dass ich von den 3 Orten, an denen ich die gleiche Funktionalität brauche nur 2 anpasse. (Das gilt für neue Mitarbeiter an einem Projekt ganz besonders, insofern machen die Funktionen den Einstieg auch einfacher.)
Ich unterstützte aber natürlich sofort, wenn QFQ auch Unittests unterstützt.

Um die Übersicht zu erleichtern, könnten wir die Funktionalität etwas einschränken.
Beispielsweise müsste jeder reusable-report in einem eigenen File sein, das in dem Ordner "reusable-reports" abgelegt ist.

Ich glaube nicht, dass das Verteilen in einzelne Dateien einen relevanten Mehrwert bietet. (Es macht es aber sicher schwieriger den Überblick zu behalten wenn sich Funktionen gegenseitig aufrufen.) Ich würde mich eher an python-Docstrings (incl. Doctest) orientieren.
Für die Übersicht wäre wohl wirklich ein Tool hilfreich, dass mir zeigt, von wo eine Funktion überall aufgerufen wird.

Also available in: Atom PDF