AJAX die nächste: Was es braucht

WBCE ist recht klassisch gestrickt. Klassisch kann aber auch alt aussehen, wenn es rundherum Neues gibt. Wo es klemmt und wie es gehen kann.

In der bereits vorhandenen Serie zum Thema „AJAX“ ging es im wesentlichen um 2 Aspekte:

1) Abschnitte nachladen, vorrangig um Ladezeit zu sparen. Das ist in der Praxis wenig sinnvoll und mit vielen Problemen behaftet.

2) Einzelne Module „AJAX-fähig“ zu machen, konkret am Beispiel des ProCalendar. Dabei liegt der Fokus speziell auf den Parametern ?day=1&month=1&year=..., die in vieler Hinsicht Ärger machen und eine elegante, zeitgemäße Nutzung erschweren.

Beide Varianten klemmen mit der Art, wie WBCE funktioniert. Bei 1) würde man auf den ersten Blick annehmen, dass WBCE sogar ideal dafür wäre, aber der Teufel steckt – unlösbar - im Detail.
Bei 2) treten keine unlösbaren Probleme auf, aber viele Räder müssten immer wieder neu erfunden werden. Räder, die sich dann gegenseitig im Weg stehen.

Schauen wir uns das nochmal konkret an.

Zielsetzung: Module sollen einfach und standardisiert AJAX-fähig gemacht werden können, wenn dies sinnvoll ist.

Was sinnvoll ist, hängt natürlich vom Modul ab. Im Falle des ProCalendars (oder Bookings oder….) geht es um die Parameter, die ein schnelles Blättern verhindern (die Seite wird immer komplett neu geladen und scrollt dabei immer auf 0). Besonders am Handy ist das nervig.

Die Parameter können auch viel Ärger mit jeder Art von Spider machen: Es werden 1000e Seiten erzeugt, in denen er sich verhängt, was wieder zahlreiche weitere Probleme verursacht. Google zB. meidet sowas. China-Bots blockieren den Server, Tools wie HTTrack sind nutzlos, Statistiken sind komplett verfälscht. Dafür reicht ein einziges Vorkommen so eines Moduls irgendwo auf der Website. (Viele wissen das gar nicht!)

Bei anderen Modulen kann es eine Sortier- oder Darstellungsfunktion geben, die sich nicht so einfach per JS umsetzen lässt, oder vieles andere. Vor allem vieles, was man heute als Standard empfindet.

Es muss also in jeden Fall so laufen, dass das Modul AJAX-fähig ist, dabei aber wesentlich vom Core unterstützt wird: Mit einem kleinen Framework, Outputfiltern, mit standardisiertem Handling.

Was vom Core kommen muss

1) Es muss eine Möglichkeit geben, eine einzelne view.php eines Moduls mit Parametern aufzurufen.
Das könnte ein Aufruf sein wie: /getsection.php?section_id = 23&weitere Parameter, die durchgereicht werden. Dieses getsection.php dient als Wrapper für die view.php und gibt nur deren Inhalt aus. Klar: Mit überprüften Berechtigungen und allem dran. Es muss auch eine standardisierte Variable oder Konstante geben, anhand derer das Modul erfahren kann, dass es jetzt per AJAX aufgerufen wurde.

2) Ein Container mit definierter ID um jeden Abschnitt, also ein <div id=“coresect_ID“>...</div> oder ähnliches. Zwar kann auch ein Modul selbst so einen Container erzeugen, das schafft aber Probleme, insbesondere kann es zu doppelten Ids kommen.

Ich sehe hier kein prinzipielles Problem außer mit vereinzelten Templates. Dennoch wäre es vielleicht sinnvoll, das alles abschaltbar zu machen.

3) Ein nicht unwesentlicher Randaspekt ist die „Blätterfähigkeit“ – also die History aufrecht zu erhalten. Das geht mit #hash und angehängten „Parametern“, also #?day=1&month=1…
Diese sollten wohl schon vom Core ausgewertet und übergeben werden.

Was von Modul kommen muss

Ein Modul braucht CSS und Javascript. Mit ersterem wird es kaum Probleme geben, aber JS kann knifflig werden, weil ja nicht so einfach „onload“ getriggert wird. Welche Funktion muss wann aufgerufen werden? Das ist nicht schwierig zu lösen, aber man muss es tun.

Es stellt sich die Frage: Sollte es überhaupt möglich sein, ein Modul ohne dessen Zutun per AJAX zu laden – etwa um das ganz oben erwähnte Nachladen von Abschnitten zu ermöglichen? Ich denke: Man sollte sich keine Steine in den Weg legen, man sollte es zumindest versuchen.

Und warum mache ich es nicht einfach?

Ganz einfach: Weil ich mich mit dem Core kaum auskenne und mich deshalb auch nicht dafür zuständig sehe. Es erscheint mir sinnvoll, die Anordung des Codes in der heiligen index.php anzupassen, da lasse ich lieber die Finger davon.

Ein großer Aufwand sollte das aber alles nicht sein, alle Teile sind schon vorhanden. Sie müssen nur mehr zusammengebaut werden.

Was die Schnittstelle zu Modulen betrifft, bin ich natürlich gerne bereit, mich einzubringen.

Zurück

Kommentare:

Erstmal vielen Dank für Deine Überlegungen und Denkanstöße.

Punkt 1) verstehe ich mangels Fachwissen nicht - aber aus meiner "Klein Doofi mit Plüschohren"-Perspektive klingt mir das eher nach einer Modulproblematik...?
Ich gebe auch zu bedenken, dass so ziemlich jede view.php anfängt mit
if defined WB_PATH == false exit "Cannot access this file directly"
(Klammern rausgelöscht, um nicht im Kommentarspamfilter hängen zu bleiben)
Da ist also wohl nichts mit irgendwie wrappen oder so.

Punkt 2) Mit div um Abschnitte herum ist das so eine Sache, das kann je nach Template/­Stylesheet zu unerwünschten Effekten führen. (Gab/­gibt es glaube ich bei den Kollegen, ist nicht auf sehr große Begeisterung gestoßen.) Da sollte es also die Möglichkeit geben, das zu (de-)aktivieren, was aber über einen entsprechende in der config.php zu definierende Konstante kein Problem sein sollte.

Punkt 3) weiß ich nicht

Die index.php ist nicht "heilig". Wenn es daran Anpassungsbedarf gibt und die Änderung daran nicht unerwünschte Seiteneffekte bzw. weitere umfangreiche Änderungen an allen möglichen Templates und Modulen nach sich zieht, kann die natürlich angefasst werden. Es muss halt ausführlich getestet werden. Je konkreter Du beschreibst, was Dir vorschwebt, um so größer ist die Wahrscheinlichkeit, dass sich dem jemand annimmt und das mal ausprobiert :)

Florian 18.01.2023
Antworten

Hallo!
Punkt 1 - /­getsection.php?section_id = 23&...: Ja, das muss sowieso eine Art index.php sein - die eben nicht die ganze Seite aufruft, sondern nur die view.php eines Moduls.
Es muss klar sein, dass Zugriffe per AJAX gleichbedeutend sind mit einem Seitenzugriff, also: Rechte, Framework, Filter - das muss alles da und geklärt sein, bevor überhaupt auf die view.php zugegriffen wird.

Punkt 2 - div als Container für jeden Abschnitt: Ja, da da gabs ungute Erfahrungen. zB mit dem Template Fruesteg. Aber da muss man wohl durch.
In die config.php würde ich den eher nicht packen, die geht sonst über und Laien können das nicht.

Wie schon gesagt habe ich keine Ahnung, was in der /­index.php genau passiert - und in der Folge. Wo wird zB das Template eingehängt? - Das muss natürlich entfallen. Auch anderes. Das ist mir zu komplex, ich rühre den Core nicht an.

Chio 18.01.2023
Antworten