User-/View-abhängige SQL-Select-Statements

Hallo Heinz,

ja, das hängt definitiv mit dem Reload zusammen.
Wenn sich das Reload-Trigger Feld ändert, dann werden die Optionen des SelectSQL per Ajax neu geladen.
Hierbei wir so wenig Code wie möglich ausgeführt.
Der ganze Code der das Formularobjekt und alle Feldobjekte aufbaut wird hier gar nicht aufgerufen.
Weil das eigentlich an dieser Stelle nicht nötig (und auch gar nicht so einfach möglich) ist.
Es wird tatäschlich einfach nur das in der Feldkonfiguration gespeicherte SQL-Statement aus der Datenbank geladen.
Alle anderen benötigen Daten (User und im Formular eingegebene Daten) stehen direkt zur Verfügung.

Es war ursprünglich nie vorgesehen, dass man das durch die Konfiguration festgelegte Feldobjekt manipulieren kann.
Der Code geht auch an anderen Stellen davon aus, dass das in der Feldkonfiguration festgelegte Feldobjekt für bestimmte Tasks ausreicht.

Es tut mir leid, aber aktuell habe ich hier keine Lösung für dich.
Über die Implikationen muss ich erst einmal nachdenken.

Wäre dir denn geholfen, wenn das SQL-Statement im Edit View gar nicht ausgeführt wird?

Liebe Grüße,
Aicha

 

Hallo Aicha, Danke für die Klarstellung und Hintergründe. Da muss ich mein Formulardesign noch einmal überdenken. Die Summe der Einzelpreise für alle  Events eines Users über mehrere Datensätze hinweg berechne ich jetzt schon im PDF-Template. Dafür brauche ich das Summe-Feld gar nicht. Die Summenberechnung während der Formulareingabe passt ja aktuell auch schon. In onVisformsBeforeFormSave schreibe ich die Summe auch in alle bisherigen Datensätze des Users (für die Datenlistenansicht). In onVisformsBeforeEditSave kann ich nun die Summe neu berechnen, falls die Felder Einzelsumme oder Nachlass/Aufpreis geändert wurden. Nachlass/Aufpreis ist ein entsprechend validiertes Textfeld. Das hätte ich ohnehin nicht durch ein Reload in meinem SQL-Statement berücksichtigen können. Daher habe ich es bisher auch nicht erwähnt. Jedenfalls kann ich nun diese Summe sowohl in $fields, als auch in die Datenbank schreiben. Damit hätte ich eigentlich alles was ich brauche. Auch in den Mails und PDF (ohne Template) passt die Summe dann immer korrekt. Die Antwort auf deine Frage ist also JA, in der EditView brauche ich das Statement nicht, das Feld selbst auch gar nicht sichtbar. Nur übertragen muss es trotzdem werden, um es in onVisformsBeforeEditSave anpassen zu können. Wie löse ich das am besten? Nur mit CSS ausblenden?

Hallo Heinz,

mit CSS ausblenden sollte reichen, da du den Wert, in der Datenbank ja ohnehin selbst anpasst.

Ich habe deine Antwort erst heute gelesen und mir übers Wochenende zu den gesamten Problematik ein paar Gedanken gemacht.
Ich bin zu dem Schluss gekommen, dass das neue frühe Event auf dem Feld sicherlich eine gute Neuerung ist, die viele interessante Dinge ermöglicht.
Aber einige Feldparameter können einfach nicht dynamisch angepasst werden, z.B. das SQL Statement.
Sie sind quasi 'protected'.
Und das wird auch so bleiben.

Meiner Meinung nach wäre der korrekte Ansatz für deine Anforderung gewesen, dass du in deinem SQL Statement ein 'Case When' drin hast.

Da du ein abweichendes Verhalten für die Edit View und angemeldete Benutzer wünschst, brauchst du im Formular zumindest ein Edit-Only Feld mit einem Defaultwert, an dem du erkennst, dass du im Edit Modus bist. Das verwendest du im 'Case When' um zu erkennen, dass du in der Edit-View bist. Und den angemeldeten Benutzer kannst du im SQL ja ohnehin daran erkennen, dass die User-Id im User Objekt nicht 0 ist.
Falls es noch weitere Parameter gibt, die beim Reload aktuell nicht mit übergeben werden, müssen die ebenfalls in Edit-Only Felder als Default-Wert rein.

Ich denke, dass es mit diesem Ansatz möglich wäre, deine konkrete Anforderung umzusetzen.
Für andere Anforderungen muss man schauen, wie man ein SQL Statement bauen kann, dass alle Fälle richtig unterscheidet.

Aber deine Lösung ist natürlich auch gut.

Herzliche Grüße,
Aicha

Mein "echtes" SQL-STATEMENT muss erstmaligen und weiteren Formularaufruf unterscheiden können. Des weiteren auf die Eingabe in einem Text-Rabattfeld und die Auswahl eines anderen Listbox-SQL-Feldes aus einer weiteren Tabelle reagieren. Zusätzlich soll die Summe in "deuteschem" Währungsformat angezeigt werden. Das habe ich nun so gelöst:

Ist schon ziemlich komplex (für meine Verhältnisse). Letztendlich scheitere ich aber dabei an der Berücksichtigung eines Rabatt-Text-Feldes ( ), was ich beim Reload nicht berücksichtigen kann (wenn man erst den Rabattwert eingibt und danach nochmals eine Option der Listbox-SQL(RELOAD) wählt, geht es behelfsmäßig) . Löse das jetzt endgültig im onVisformsAfterEditFormSave, wenn der bearbeitete Datensatz auch wirklich final gespeichert wurde. Dort berechne ich die $summe aller Einzelpreise und Rabatte aus allen Datensätzen eines Users mit

und aktualisiere dessen Datensätze mit

So habe ich alles was ich brauche. Für mich die einfachste und sicherste Berechnung, die für alle Ansichten passt. Vielen Dank Aicha für deine Hilfe.

Hallo Heinz,

das neue Feature ist enthalten im neusten Release vom 12.10.2023 für Joomla 4:
Visforms 4.3.1
docs.joomla-4.visforms.vi-solutions.de/updates/version-4-3-1/
Visforms Subscription 4.3.1
docs.joomla-4.visforms.vi-solutions.de/u...s/sub-version-4-3-1/

Liebe Grüße, Ingmar