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

Mit der Subscription Version 4.3.0 Beta sind mit dem Event 'onVisfieldBeforeCreate' ja prinzipiell vom aktuellen User abhängige SQL-Select-Statements möglich.
Welche Objekte sind innerhalb dieses Events bekannt? Zusätzlich von dem mir bekannten USER und INPUT (und FIELD natürlich) benötige ich speziell noch die Kontext-Unterscheidung zwischen Form und Edit an dieser Stelle. Außerdem im Falle von Edit zusätzlich den aktuellen Datensatz (zumindest ID und created_by).
Kann ich auf das $form-Objekt an dieser Stelle zugreifen? Dann hätte ich ja alles was ich brauche.

Hintergrund ist, dass das SQL-Feld eine Summenberechnung unter Einbeziehung von eigenen User- und Eingabedaten über mehrere eigene Datensätze hinweg durchführt. Beim Editieren passt dann das SQL-Statement nicht mehr, weil ja der Admin editiert. Selbst eigene Datensätze editieren ist dann nicht mehr korrekt möglich, da einzelne Werte des aktuell bearbeiteten Datensatz ja auch schon im (gleichen) gespeicherten Datensatz enthalten sind. Für eine korrekte Summenberechnung würde also so etwas gebraucht: Summe einer Spalte aller gespeicherten Datensätze außer dem aktuellen, plus Summe aus dem aktuellen Input-Objekt. 

Hallo Heinz,

aktuell steht dir das Formular als Objekt im Event leider nicht zur Verfügung. Mir war nicht klar, dass das auch gebraucht wird.

Ich habe dazu einen Issue zur Entwicklung für die Wunschliste angelegt:
Issue [VF-844]: onVisfieldBeforeCreate make form available in event   
 
Wenn wir das neue Feature releasen, wirst du explizit über das Release hier im Thema informiert.
Vielen Dank nochmal für deinen Vorschlag!

Herzliche Grüße,
Aicha

Hallo Heinz,

Falls du das jetzt schon nutzen willst.

Die Code-Anpasungen wird so aussehen:

Es gibt im Verzeichnis components/com_visforms/lib/field für jeden Feldtyp eine Datei.
In allen diesen Dateien wird das Event onVisfieldBeforeCreate getriggered (AUßER image.php, multicheckbox.php, multicheckboxsql.php, password.php, reset.php, die rein abgeleitete Klassen sind und keinen eigenen Code enthalten).

So um die Zeile 43 (variiert je nach Datei).
Alt: Neu: Dieser Code muss in 19 Dateien in diesem Verzeichnis anpassen (eben allen außer image.php, multicheckbox.php, multicheckboxsql.php, password.php, reset.php).
Wenn du Dateien vergisst erhälst du Fehlermeldungen und evtl. auch fatal Errors!

Nachdem alle Dateien angepasst sind steht dir in deinem EventHandler im Plugin ein 3 Parameter $form zur Verfügung.

Das $form Objekt hat einen Parameter displayState. Der kennt 4 Werte.
1 = Formularansicht
2 = Fehlerhaftes Formular wird erneut angezeigt (also auch eine Formularansicht, aber es gibt schon Benutzereingaben und diese werden eingefügt. Dieser Status wird also durchlaufen, wenn das Formular abgeschickt wurde, aber PHP Validierung hat einen Fehler erkannt hat und das Formular erneut angezeigt wird)
3 = Formular Edit Ansicht
4 = Fehlerhaftes Edit Formular wird erneut angezeigt (analog 2, aber beim Edit Modus).

Damit solltest du alle benötigten Informationen haben.

Herzliche Grüße,
Aicha
 

Eieiei .. das ging ja fix ... das teste ich gleich mal ...

Also Aicha, ...  das klappt hervorragend ... bin wieder mal begeistert ... kann den 'displayState' je nach Ansicht korrekt auslesen.
Absolute Spitze und eine super schnelle Lösung.
Vielen Dank! 

Obwohl das SQL-Statement nun korrekt ersetzt wird, die SQL-Abfrage auch korrekt funktioniert, der richtige Wert auch kurz zu sehen ist, wird er scheinbar etwas später wieder durch das alte SQL-Statement aus der Feldkonfiguration ersetzt. Zum Testen habe ich mehrere Datensätze mit einer UserID(1) erstellt und mit einer anderen UserID(2) ändern wollen. Das Feld 'F352' enthält Einzelpreise. Das (Test)-Statement im Formular für das Summe-Feld 408 lautet:

Bei jedem neuen Formularaufruf durch User(1) wird die Summe aus bisherigen Einzelpreisen und der aktuellen Eingabe korrekt berechnet.
Im Event onVisfieldBeforeCreate wird (nur für EDIT) das Summenfeld F408 - Statement ersetzt mit:


Leider scheint das nicht zu reichen, denn wenn ich mit User(2) editiere, springt die kurz richtige Anzeige wieder zurück auf {input:neue_eingabe}.
Wenn ich mit User(1) editiere, sehe ich auch kurz die richtige Berechnung, dann aber, wenn das Formular fertig aufgebaut scheint, ergibt die Berechnung: die Summe aller bisher gespeicherten Einzelsummen des Users + die aktuelle 'neue_eingabe'. Das entspricht exakt dem Verhalten des SQL-Statements aus der Formularkonfiguration für Feld 408.

In einem anderen Formular konnte ich aber erfolgreich: dauerhaft (dort für alle Ansichten, also Form und Edit) umsetzen.
Mein Summenfeld ist ein "Reload"-Feld bei Änderung von 'neue_eingabe'. Hängt das eventuell damit zusammen? An der falschen Berechnung ändert das zumindest nichts.