Joomla 5 Notice

We are pleased to announce that as of January 29, 2024, all of our Joomla extensions are compatible with Joomla 5.

For all who are still updateing from Joomla 3 to Joomla 4: Joomla 4 Migration instructions are available here:

There is now a separate Documentation for Visforms for Joomla 4 and for Visforms for Joomla 5!

Forum

Visforms Subscription user can ask questions in our forum. Please log in with the relevant user first.
Everybody can access the forum for reading.

Please only ask 1 question per topic.

Important information for almost every question:
V1: Which Visforms version is running?
V2: Which Joomla version is running?
V3: Which PHP version is running?

Due to public holidays and vacations, longer response times can be expected for inquiries in the forum between December 20, 2024 and Janaury 8, 2025.

Timing beim Abarbeiten von Scripten mit Reload-Feldern

More
4 months 23 hours ago - 3 months 4 weeks ago #10686 by MaliRaj
Hallo ihr fleißigen Bienchen.
Um mit Hilfe von FEWA Formularwerte neu zu setzen nutze ich ... (visformsInitialised, function() ... um zu warten, bis die Werte wirklich auch da sind.
Während des Ausfüllens des Formulars werden nun immer wieder mehrere ListboxSQL nachgeladen/neu ausgeführt. Deren Ergebnisse werden in Funktionen zum Berechnen benötigt, stehen aber nach einem .change() zum Zeitpunkt der Berechnung noch nicht vollständig zur Verfügung. In der langsameren lokalen Entwicklung tritt das häufiger auf, aber auch im Live-System. Um zu warten, nutze ich momentan setTimeout. Knifflig, wenn man nicht weiß, ob das Ergebnis 'null' ist oder einfach nur noch etwas länger dauert. Wie löse ich das am besten? Gibt es ein 'visformsUpdated' oder ähnliches nach einem change?

Nachtrag:
Nach dem Tipp von Ingmar nutze ich nun FireFox. Der läuft sehr viel schneller, so dass kaum noch Timingprobleme auftreten und ich auf setTimeout wieder verzichten kann. Mit einem 'visformsUpdated' bin ich vermutlich eh auf dem Holzweg. on.change() ist ja schon das Event (definitiv nach Änderung).

Freundliche Grüße aus PM
Heinz
(Joomla 5.1.2 / Visforms+Subscription 5.12 / PHP 8.2)
Last edit: 3 months 4 weeks ago by MaliRaj.

More
3 months 3 weeks ago #10709 by Administrator IV
Replied by Administrator IV on topic Timing beim Abarbeiten von Scripten mit Reload-Feldern
Hallo Heinz,

Tatsache ist der folgende Ablauf:
- Benutzer ändert einen Feld-Wert,
- abhängiges SQL-Feld beginnt sich neu zu laden,
- abhängiges SQL-Feld erhält asynchron 'irgendwann' seinen neuen Wert vom Server und setzt ihn im Formular-Feld,
- abhängiges SQL-Feld setzt seinen neuen Wert in sein Formular-Feld,
- abhängiges SQL-Feld hat sich geändert,
- abhängiges SQL-Feld feuert ein Change-Event,
- auf das Change-Event des abhängigen SQL-Feldes horchende JavaScript-Handler lesen den neuen Wert des abhängigen SQL-Feldes aus.

Alles JavaScript, dass auf das Change-Event des SQL-Feldes horcht,
- wird im Handler notifiziert,
- kann den geänderten Wert auslesen.

Bisher gibt es auch bei einem sehr langsam ablaufenden JavaScript grundsätzlich erstmal keinerlei Timing-Probleme.
In den Rechenfeldern funktioniert das auch mit mehreren abhängigen Input-Feldern innerhalb der Berechnung ohne Timing-Probleme.

Es kommt auf die genauen Details deiner Lösung an.
Eventuell verwendest du mehrere SQL-Felder in einer Berechnung und hast damit auch mehrere Change-Events von mehreren SQL-Feldern.
Diese verschiedenen SQL-Felder
- holen unabhängig voneinander asynchron via AJAX ihre neuen Werte vom Backend,
- sind alle unterschiedlich schnell fertig,
- feuern alle ihr eigenes Change-Event früher oder später.

Frage: Unterscheidet sich deine Lösung grundsätzlich von dem ganz oben skizzierten Ablauf und wenn ja wie genau?

Oder anders formuliert: Was machst du grundsätzlich anders?

Liebe Grüße, Ingmar

:idea: I recommend you the new and up-to-date documentation for Joomla 4:
docs.joomla-5.visforms.vi-solutions.de/en/docs/
Most of this also applies retrospectively to Joomla 3.
Please only ask 1 question per topic :-).

:idea: Ich empfehle Dir die neue und aktuelle Dokumentation für Joomla 4:
docs.joomla-5.visforms.vi-solutions.de/docs/
Das meiste gilt rückwirkend auch für Joomla 3.
Bitte immer nur 1 Frage pro Thema stellen :-).
The following user(s) said Thank You: MaliRaj

More
3 months 3 weeks ago - 3 months 3 weeks ago #10712 by MaliRaj
Hallo Ingmar,
der Ablauf ist schon so wie von dir beschrieben. Bei mir löst, noch bevor der Nutzer ein Feld ändert, das SQL-Feld  ein change aus, was ich mir nicht erklären kann. Joomla-Test-Installation auf XAMPP. Mein Feld 'kurort' ist ein Radio mit nur 2 Optionen für zwei Kurorte. Es ist ein Pflichtfeld, aber ohne Vorauswahl. Die Anzeige von 'kurort' ist selbst zwar auch abhängig von einem weiteren Radio, welches aber eine Standardauswahl hat und somit immer angezeigt wird. Das SQL-Feld 'kurzeit' wird neu geladen, wenn sich 'kurort' ändert und versteckt, solange das SQL kein Ergebnis liefert. Das SQL-Statement nutzt lediglich input:kurort, um aus 2 unterschiedlichen Tabellen Zeiträume auszulesen und strukturiert zur Auswahl anzubieten.
Für das Formular habe ich ein (FEWA)
Code:
 //    bildSyntax löschen bei Änderung von Kurzeit und Gruppe, um Neuberechnung zu erzwingen                 $('#' + kurzeitField).change(clearSyntaxField);

was auf Änderungen des SQL reagiert. Den Aufruf von clearSyntaxField überwache ich mit dem Debugger im Browser. Beim Laden des Formulars passiert nun Folgendes:
- Radio 'kurort' wird angezeigt, keine Option ist ausgewählt
- SQL-Listbox 'kurzeit' wird kurz angezeigt, dann aber ausgeblendet. Das dürfte wegen 'hideOnEmptyList' normal sein, da das SQL durch den noch fehlenden Kurort kein Ergebnis liefert.
- nach ca. 10 Sekunden (ohne irgendwelche Eingaben) wird ein change auf dem SQL-Feld ausgelöst. So wie ich es erkennen kann von jquery.min.js, und zwar 3x hintereinander, wobei $('#' + kurzeitField).val() immer '' ist. Hier lautet meine Frage: Warum wird ein change ausgelöst? Die lange Zeit von gut 10 Sekunden ist sicher meinem langsamen Testsystem geschuldet. Außerdem gibt es im Formular weitere SQL-Listboxen, die ebenfalls in Abhängigkeit von 'kurort' und 'kurzeit' als Trigger unterschiedlichste Daten bereitstellen, allesamt bleiben sie letztlich ausgeblendet, da 'kurort' und 'kurzeit' leer sind und immer "ohne Ergebnis verstecken" gesetzt ist. 
Mein Workaround ist jetzt, dass ich kurort und kurzeit mit 
Code:
$('.visform').bind('visformsInitialised', function() {
speichere und in clearSyntaxField mit den aktuellen Werten vergleiche und entsprechend weiter verfahre.
Ich hatte auch erst mein SQL aus 'kurzeit' im Verdacht, aber da sich 'kurort' nie ändert, habe ich das ausgeschlossen. Hier der Vollständigkeit halber mein Statement:
Code:
SELECT CONCAT('1_',`DG1`) AS value, CONCAT('1_',`DG1`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('2_',`DG2`) AS value, CONCAT('2_',`DG2`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('3_',`DG3`) AS value, CONCAT('3_',`DG3`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('4_',`DG4`) AS value, CONCAT('4_',`DG4`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('5_',`DG5`) AS value, CONCAT('5_',`DG5`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('6_',`DG6`) AS value, CONCAT('6_',`DG6`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('7_',`DG7`) AS value, CONCAT('7_',`DG7`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('8_',`DG8`) AS value, CONCAT('8_',`DG8`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('9_',`DG9`) AS value, CONCAT('9_',`DG9`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT CONCAT('10_',`DG10`) AS value, CONCAT('10_',`DG10`) AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT `Jahr` AS value, CONCAT(`Jahr`,' - Kurzeit manuell ins Info-Feld eintragen!') AS label, `Jahr` AS jahr FROM `#__kurdaten_${input:kurort}` UNION  SELECT `Jahr` AS value, CONCAT(`Text`,' - Kurzeit manuell ins Info-Feld eintragen!') AS label, `Jahr` AS jahr FROM `#__kurdaten_unbekannt` order by jahr, value
Gleiches passiert auch beim Editieren eines Datensatzes. Da sind ja alle Felder mit den Werten aus der Datenbank ausgefüllt. Aber auch da wird nach ca. 10 Sekunden wieder 3x nacheinander ein change für das SQL 'kurzeit' ausgelöst, ohne dass sich der ausgewählte Wert geändert hat. 

Freundliche Grüße aus PM
Heinz
(Joomla 5.1.2 / Visforms+Subscription 5.12 / PHP 8.2)
Last edit: 3 months 3 weeks ago by MaliRaj.

More
3 months 3 weeks ago - 3 months 3 weeks ago #10714 by MaliRaj
Das (mein) Problem lässt sich ganz einfach reproduzieren. Dazu braucht es nur 2 Felder, ein Radio mit 2 Optionen und ein SelectSQL, mit Reload bei Änderung vom Radio. Getestet auf einem frischen Joomla 5, Visforms Version 5.1.2, Subscription Version 5.1.2, keie Custom Plugins, nur FEWA aktiviert.
 
 
folgendes MiniScript in FEWA Formular & Daten-Edit
Code:
jQuery(document).ready(function() {     var sqlField     = 'field16';    // SelectSQL     $('#' + sqlField).on('change', function() {     debugger;     }); });

Das Formular wird über einen Menüpunkt aufgerufen.
Ohne dass etwas eingegeben oder geändert wird, wird das change-Event 3x gefeuert. Grund dafür ist der Eintrag "Bei Änderung nachladen" im SQL-Feld. Ohne eine Nachladeoption wird das Event 1x gefeuert.
Gleiches Verhalten bei der Daten-Edit-Ansicht.
Wie erreiche ich denn unter diesen Umständen, dass meine Funktionen wirklich nur auf eine Änderung von Werten reagieren?

Freundliche Grüße aus PM
Heinz
(Joomla 5.1.2 / Visforms+Subscription 5.12 / PHP 8.2)
Last edit: 3 months 3 weeks ago by MaliRaj.
The following user(s) said Thank You: Administrator IV

More
3 months 3 weeks ago #10715 by Administrator IV
Replied by Administrator IV on topic Timing beim Abarbeiten von Scripten mit Reload-Feldern
Hallo Heinz,

herzlichen Dank für diese beeindruckende Vorlage!
Die Reproduktion des Verhaltens ist natürlich echt Spitze, um gut voranzukommen.
Ich möchte es nachstellen und analysieren.

Die Frage ist, ob du uns ein Akeeba-Backup der Webseite zum Debuggen zur Verfügung stellen könntest.
Wir nutzen dazu die folgende Plattform: wetransfer.com/
Verwende die E-Mail Adresse des Forums als Empfänger: forum (--at--) vi-solutions.de.

Liebe Grüße, Ingmar

:idea: I recommend you the new and up-to-date documentation for Joomla 4:
docs.joomla-5.visforms.vi-solutions.de/en/docs/
Most of this also applies retrospectively to Joomla 3.
Please only ask 1 question per topic :-).

:idea: Ich empfehle Dir die neue und aktuelle Dokumentation für Joomla 4:
docs.joomla-5.visforms.vi-solutions.de/docs/
Das meiste gilt rückwirkend auch für Joomla 3.
Bitte immer nur 1 Frage pro Thema stellen :-).
The following user(s) said Thank You: MaliRaj

More
3 months 2 weeks ago #10719 by MaliRaj
... ist unterwegs ...

Freundliche Grüße aus PM
Heinz
(Joomla 5.1.2 / Visforms+Subscription 5.12 / PHP 8.2)

Moderators: Administrator AVAdministrator IV
Powered by Kunena Forum