AJAX die nächste: Was es braucht

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