DOMParser und Progressive Enhancement

[Rolf B]

Hallo pl,

native CGI ist für das Thema wohl irrelevant, würde ich zu behaupten wagen :)

DOMParser ist hinreichend unterstützt, aber ich frage mich, warum Du nicht einfach responseType auf "document" setzt und das gelieferte Document-Objekt nutzt?

Ein Service-Endpoint, der die Umrechnung durchführt und sich einen gemeinsamen Funktionskern mit dem Browser-Endpoint teilt, ist aber auch nicht sooo viel mehr Aufwand. Wenn Du jetzt damit argumentieren solltest, dass das unter Native CGI zu viel Arbeit macht, hast Du ein Argument gegen Native CGI geliefert 😉

Deine HTML Scraping Lösung ist gut gemeint, aber nicht zu Ende gedacht. Als Verbesserung würde ich Dir, in Anlehnung an ASP.NET, eine class "updatePanel" empfehlen.

<form action="/jd.html">
    <fieldset class="updatePanel" id="scaligerRechner" style="padding:1em"><legend><strong><label for="date">Datum links</label>, <label for="jd">Scaliger-Tag rechts</label></strong></legend>
        <input name="date" id="date" value="22.2.2019" title="Beliebiges Datum" data-submitDefault="date2jd">

        <input type="submit" name="date2jd" id="date2jd" value="Datum zu JD >">
        <input type="submit" name="jd2date" id="jd2date" value="&lt; JD zu Datum">

        <input name="jd" id="jd" value="2458537" title="Fortlaufender Tag" data-submitDefault="jd2date">

        <span>Wochentag: <em id="wochentag">Freitag</em></span>
    </fieldset>
</form>

Das fieldset ist das Update-Panel. Das Form könnte es auch sein. Ablauf im Submit-Event:

1. Prüfe, ob das Form ein updatePanel ist oder updatePanel-Elemente enthält. Wenn nein: Normaler Submit

2. Browser-Submit verhindern und Submit-Button bestimmen. Deine Lösung ist ein Anfang, aber unzureichend. Du musst prüfen:

   1. War der Fokus auf einem Button oder input type="button"? Dann ist das der Submit-Button

   2. Bei Fokus auf einem anderen input- oder textarea-Element brauchst Du Hilfe. Ich würde ein data-Attribut vorschlagen: data-submitDefault. (Ein aria-Attribut wie aria-owns oder aria-controls passt semantisch nicht, und ein Missbrauch von for wäre auch nicht gut). Das Attribut kann auf fokussierbaren Elementen, ihren Elternelementen oder dem Form liegen. Du guckst vom Fokus-Element bis hoch zum Form, ob Du dieses Attribut findest. Darin steht die ID des Submitbuttons, der zu verwenden ist.

   3. Primitivere Lösungen dieses Problems könnte mit Namenskonventionen für IDs arbeiten, an Hand derer aus der input-ID die button-ID ableitbar ist, aber das ist meiner Meinung nach zu fragil. Man könnte es auch mit Klassen lösen - ein Button und die inputs, aus denen heraus der Button bei ENTER-Submit zu nutzen ist, haben einfach alle die gleiche Klasse. Welche das ist, wäre wieder per Namenskonvention zu regeln, um nicht über die falsche Klasse einen falschen Match zu bekommen. Wie gesagt: das sind primitivere Lösungen. Meine data-Attribut Idee gefällt mir besser.

3. Formdata per Ajax submitten.

4. AJAX-Antwort parsefähig machen (DOMParser oder responseType="document".

5. Zu jedem updatePanel auf der aktuellen Seite via ID das korrespondierende updatePanel in der Antwort suchen und innerHTML austauschen.

Das ist dann generisch und nicht auf ein konkretes Form ausgelegt. Wie man die UpdatePanels schneidet, muss man je nach Anwendungszweck analysieren. Und man könnte auch im Ajax-Request per Header oder Zusatzparameter mitteilen, dass dies ein Update-Aufruf ist, so dass ein informierter Server daraufhin seine Antwort optimieren kann (nicht muss).

Rolf