[PLUGIN] Ocal_XH

[cmb]

Hallo Beat + Susanne,

Stündlich ist perfekt

Freut mich.

Listenansicht ist von unserer Seite her nicht nötig

Vielleicht aber für Mietinteressenten (nicht jeder hat CSS, und es gibt ja auch Rot-Grün-Sehschwächen). Ich liefere diese auf jeden Fall noch nach (im Zweifel täglich gegliedert).

Wir haben das Plugin integriert, funktioniert einwandfrei.

Prima.

Ganz herzlichen Dank!

Ich danke Euch, da die neue Funktionalität ist eine sinnvolle und passende Erweiterung von Ocal_XH ist, und das Plugin nützlicher macht.

Christoph

[Holger]

Hallo Christoph,

ich überlege, ob ich das Plugin in einem Projekt einsetzen kann. Dabei geht es um mehrere Mietobjekte, deren Präsentation und Auswahl durch ein eigenes Plugin generiert wird. Der Aufruf von Ocal aus dem Plugin heraus ist ja kein Problem. Auch die Administration der Kalender funktioniert gut .
Probleme habe ich jedoch mit der Paginierung. Ein Beispiel:
die Mietobjekte werden z.B. in Tabs dargestellt; im dritten Tab ist vielleicht der Kalender platziert. Um überhaupt die Detailseite darzustellen, braucht mein Plugin URL-Parameter (z.B. die id und den Anzeige-Mode). Da Ocal die Paginierung über normale Seiten-Requests realisiert, sind natürlich "meine" URL-Parameter erst 'mal "verloren". Als Quick&Dirty-Lösung - und damit ich nichts am Code von Ocal ändern musste - hänge ich alle notwendigen Parameter jetzt per JS an die Paginierungs-Links an. Das geht zwar, aber das nächste Problem ist dann das Springen der Seite, wegen eines fehlenden Anker-Links. Den könnte ich zwar auch anhängen oder irgendwie anders generieren, aber das funktioniert nicht unbedingt sauber mit meiner Tab-Lösung... .

Klasse wäre es, wenn Du die Paginierung, wie auch bei der Administration des Kalenders, zumindest alternativ, auch mit AJAX-Requests machen könntest. Ich kenne zwar Deine Abneigung gegenüber JS, aber bei FF kann der "normale" User das heutzutage nicht mal mehr problemlos abstellen. Und im oben dargestellten Szenario müsste auch JS herhalten, ansonsten ist das Plugin - zusammen mit anderen Plugins in einer Seite - leider nicht einsetzbar. Und diesen Einsatzfall sehe ich gerade für Ocal nicht als außergewöhnlich an.

LG
Holger

[cmb]

Hm, das ist eigentlich ein allgemeines Problem, das nicht nur Ocal_XH betrifft, sondern immer dann auftreten dürfte, wenn wenigstens zwei Plugins auf einer Seite im Einsatz sind, die zusätzliche Query-Parameter in der URL verwenden. Anstatt die URLs per JS fixen zu müssen, sollten sie einfach korrekt erzeugt werden. Der "Klassiker" ist ja:

Code: Select all

$url = $sn . '?' . $su . '&parameter=wert'; 

und da liegt meiner Meinung nach der Hund begraben. Richtiger wäre es also von der gesamten aktuellen URL auszugehen, und die zusätzlichen Parameter zu ersetzen (falls bereits vorhanden) oder anzuhängen (falls nicht):

Code: Select all

parse_str($_SERVER['QUERY_STRING'], $params);
$params['parameter'] = 'wert';
$query = http_build_query($params);
$url = $sn . '?' . $query; 

Wenn sich alle Plugins an diese Konvention hielten, dann sollte es eigentlich keine Probleme mehr geben. Wichtig ist es dann halt, beim Ausgeben als HTML htmlspecialchars() oder besser XH_hsc() zu verwenden (was sowieso nicht schaden kann).

Die nötige Anpassung für Ocal_XH in Ocal_View::renderPaginationLink sollte nicht schwer sein.

Was hältst Du davon?

PS: So wie der Code ist, funktioniert es nicht, weil der Seitenname nicht erkannt würde. Vielleicht tut es schon folgende Ergänzung:

Code: Select all

$query = str_replace('=&', '&', $query);

[Holger]

Hallo Christoph,

Was hältst Du davon?

Ja, das ist ein generelles Problem und sollte nicht im Einzelfall, sondern besser mit der geplanten Plugin-API gelöst werden. So wird man dann leichter bestehende Plugins anpassen können und die Akzeptanz der Pluginautoren wird dann sicherlich schneller erreicht.

Aber, wie schon geschrieben, ist mein wirkliches Problem ja nicht der Verlust der URL-Parameter. Das ist auch ohne Modifikation an den Plugins und somit updatesicher lösbar.
Mich stört der Page-Reload beim Blättern des Kalenders generell. Das passt IMO konzeptionell einfach nicht (mehr) in eine moderne Webanwendung. Entweder muss die Seite zu Ankern springen, oder der User muss mehr oder weniger weit scrollen.
Leider kann ich Dir noch keine Demo des Tools zeigen -- aber ich setze gerne eine Installation auf, wenn es nötig wäre.
Ocal gefällt mir insgesamt gut. Nur stelle ich, aus Platzgründen, in der Seite nur 4 Monate dar und blättern im Kalender wird da wohl oft nötig sein.
Ich habe jetzt keine Ahnung, wie aufwändig die Umstellung von Ocal auf Ajax-Requests ist. Aber wenn das nicht möglich ist werde ich wohl besser auf ein altes Tool von mir[1] zurück greifen. Das nutzt leider MySQL und ist etwas in die Jahre gekommen, aber eventuelle Anpassungen bekomme ich da leichter hin...

LG
Holger

[cmb]

Aber, wie schon geschrieben, ist mein wirkliches Problem ja nicht der Verlust der URL-Parameter. Das ist auch ohne Modifikation an den Plugins und somit updatesicher lösbar.
Mich stört der Page-Reload beim Blättern des Kalenders generell. Das passt IMO konzeptionell einfach nicht (mehr) in eine moderne Webanwendung. Entweder muss die Seite zu Ankern springen, oder der User muss mehr oder weniger weit scrollen.
[...]
Ich habe jetzt keine Ahnung, wie aufwändig die Umstellung von Ocal auf Ajax-Requests ist

Wer lesen kann, ist klar im Vorteil.

Wirklich auf Ajax-Requests umstellen will ich nicht, aber natürlich ist es sinnvoll diese optional anzubieten (falls eben JS mit XHR verfügbar). Das habe ich bei Chess_XH z.B. auch so gemacht, und allzu aufwendig ist es nicht unbedingt, wenn man einfach ein HTML-Fragment zurückgibt. Ich schau mir das gleich mal näher an.

[Holger]

Entweder muss die Seite zu Ankern springen,

Schön gedacht, funktioniert aber nicht. Da dann an der URL ein Anker (#AnkerName) angehängt ist, kann Ocal Änderungen nicht mehr speichern, da -- zumindest FF -- den Query-String hinter dem Anker scheinbar nicht auswertet

[Holger]

und allzu aufwendig ist es nicht unbedingt, wenn man einfach ein HTML-Fragment zurückgibt. Ich schau mir das gleich mal näher an.

Das wäre super-klasse denn, wie oben beschrieben, funktionieren die Workarounds ja nicht wirklich .

[cmb]

Entweder muss die Seite zu Ankern springen,

Schön gedacht, funktioniert aber nicht. Da dann an der URL ein Anker (#AnkerName) angehängt ist, kann Ocal Änderungen nicht mehr speichern, da -- zumindest FF -- den Query-String hinter dem Anker scheinbar nicht auswertet

Das Problem ist nicht der FF, sondern Ocal_XH, das einen unsinnigen Request an den Server sendet, wenn die URL ein Fragment enthält. Diesen Bug habe ich nun behoben, und ebenso das Überschreiben fremder Query-Parameter. Auch eine rudimentäre Ajax-Paginierung ist nun implementiert (war soweit wirklich keine große Sache), die nur als Entwurf zu verstehen ist (nach Betätigung der Paginierung funktioniert das Speichern nicht mehr, es erfordert überhaupt sehr moderne Browser, Fehlerbehandlung fehlt, und so weiter und so fort). Du kannst es Dir aber gerne schon mal anschauen (master.zip). Ich versuche morgen da weiter zu machen.

[Holger]

Vielen Dank, dass Du da so schnell reagiert hast

Du kannst es Dir aber gerne schon mal anschauen

Hab's eben getestet:

...wenn die URL ein Fragment enthält. Diesen Bug habe ich nun behoben

Klappt. Anker-Fragmente werden sauber heraus gefiltert.

und ebenso das Überschreiben fremder Query-Parameter.

Funktioniert ebenfalls. Bestehende Query-Parameter bleiben erhalten.

Auch eine rudimentäre Ajax-Paginierung ist nun implementiert

Da ist, neben dem Speichern-Problem noch ein kleiner Bug: beim "Heute" Link werden leere Parameter für Jahr/Monat/Tag mitgesendet. Da landet man per Klick dann zu Christi Geburt . Hier wird eine Sonderbehandlung genügen, die die 3 Parameter für diesen Link dann nicht mitsendet.

Insgesamt schaut alles schon ganz prima aus! Ein ganz anderes Bedienungsgefühl: kein Reload kein Scrollen.. Perfekt . Und es funktioniert natürlich nun auch sauber innerhalb von Tabs.

Ich hoffe es macht nicht zu viel Mühe, die restlichen Probleme noch zu lösen...

LG
Holger

[Holger]

Hmm, das Problem mit dem "Heute" - Link muss man wohl explizit für ocal_year und ocal_month lösen, z.B.:

Code: Select all

 protected function modifyUrl(array $newParams)
    {
        global $sn;
        parse_str($_SERVER['QUERY_STRING'], $params);
        unset($params['ocal_ajax']);
        $params = array_merge($params, $newParams);
        foreach(array('ocal_year', 'ocal_month') as $param) {
            if (isset($params[$param]) && $params[$param] === '') {
                unset($params[$param]);
            }
        }
        $query = str_replace('=&', '&', http_build_query($params));
        return $sn . '?' . $query;
    }
} 

Eleganter wäre

Code: Select all

 $params = array_filter($params); 

was leere Elemente aus dem Array entfernen würde, das klappt aber schon alleine wegen des Seitennamens in der URL nicht -- und wäre wohl auch unsicher, falls ein anders Plugin bzw der Core (&normal etc.) einen leeren Eintrag verwendt.