Pit: Clientarbeit durch Serverarbeit ersetzen?

Hallo Forum,

ich versuche mich ja derzeit an einer Terminverwaltung. Termine eintragen, ermitteln, anzeigen, usw. ist bisher ganz gut angegangen und funktioniert.

Mein derzeitiges Problem: Wenn ein neuer Termin eingetragen oder ein alter editiert wird, wärs ja schön, wenn der Terminkalender genau dort stehen bleibt, wo der User sich gerade befindet und er dennoch das Ergebnis seines Eintrags/Edits sieht. Sprich, eine Sache für Javascript.

Meine derzeitige Vorgehensweise: JQuery-Dialog öffnet einen Selbigen, dort wird per Ajax die relevante Information weitergegeben an ein Backendscript. Dieses verarbeitet alle Informationen db-mäßig und gibt ein JSON Objekt an das Frontendscript zurück. Dieses verwertet die Daten im Success-Fall und macht dann per JS etwas, z.b. Klasse ändern, Dateneintrag anzeigen, na eben, was nötig ist.

Mal eine Frage: Könnte ich mir das ganze JS-Geschrafel sparen und einen Request durchführen, der den User wieder exakt an die Stelle führt, wo er im Kalender gerade steht? Dann wäre Vieles (auch, wenn ichs ja jetzt schon programmiert habe) einfacher…

Pit

  1. Tach!

    Könnte ich mir das ganze JS-Geschrafel sparen und einen Request durchführen, der den User wieder exakt an die Stelle führt, wo er im Kalender gerade steht?

    Die einzige Möglichkeit, ohne Javascript eine Positionierung innerhalb einer Seite vorzunehmen, ist ein seiteninterner Verweis, der beim Seitenladen angesprungen wird.

    dedlfix.

    1. Hello,

      Könnte ich mir das ganze JS-Geschrafel sparen und einen Request durchführen, der den User wieder exakt an die Stelle führt, wo er im Kalender gerade steht?

      Die einzige Möglichkeit, ohne Javascript eine Positionierung innerhalb einer Seite vorzunehmen, ist ein seiteninterner Verweis, der beim Seitenladen angesprungen wird.

      ... in der URi kann das Fragment dauerhaft stehenbleiben (#go). Im Dokument baut das Backend die Marke bei der Response passend ein.

      Liebe Grüße
      Tom S.

      --
      Es gibt nichts Gutes, außer man tut es!
      Das Leben selbst ist der Sinn.
      1. Hallo Tom,

        ... in der URi kann das Fragment dauerhaft stehenbleiben (#go). Im Dokument baut das Backend die Marke bei der Response passend ein.

        kannst Du mir das genauer erklären? Ich versteh nicht ganz, was Du meinst…

        Pit

        1. Hello,

          ... in der URi kann das Fragment dauerhaft stehenbleiben (#go). Im Dokument baut das Backend die Marke bei der Response passend ein.

          kannst Du mir das genauer erklären? Ich versteh nicht ganz, was Du meinst…

          Du benötigst doch ein Action-Ziel oder eine URi für Post- oder Get-Requests.

          <a href="/details/20171112/#go">Details anzeigen</a>  
          
          <form action="/insert/20171112/#go" method="post" enctype="multipart/form-data">
             ... 
          </form>
          

          Das Fragment (#go) kann immer auf Vorrat eingebaut werden. Und wenn dann das Backend enstscheidet, dass am Frontend zu einer bestimmten Stelle gescollt werden soll, dann braucht es nur den Fragmentwert als Ziel einzubauen

          <span id="go"><span>
          <div id="xyz123"> 
             Daten, Daten, Daten
          </div>
          

          Liebe Grüße
          Tom S.

          --
          Es gibt nichts Gutes, außer man tut es!
          Das Leben selbst ist der Sinn.
          1. Hallo Tom,

            Das Fragment (#go) kann immer auf Vorrat eingebaut werden. Und wenn dann das Backend enstscheidet, dass am Frontend zu einer bestimmten Stelle gescollt werden soll, dann braucht es nur den Fragmentwert als Ziel einzubauen

            <span id="go"><span>
            <div id="xyz123"> 
               Daten, Daten, Daten
            </div>
            

            Aha, korrekt. Jetzt verstehe ich, was Du meinst. Ist von der Technik sicher machbar und gefällt mir.

            Bleibt aber immer noch, dass ein komplett neuer Seitenaufbau stattfinden muß. (Hast Du da einen Tip, wie man das etwas "smoother" hin bekommt als "Seite weg - weißer Bildschirm - Seite wieder da"?

            Ich weiß im Moment einfach nicht, ob ich mich damit (Umbau auf serverbasiertem Dateneinsatz) einen Schritt vor oder zurück bewege und sucher so ein wenig nach der eierlegenden Wollmilchsau. Vor allem programmiere ich derzeit ja ohnehin Beides: JS und Serverbasierten Einsatz der Daten. (Edit der Daten habe ich nooch gar nicht angefangen)

            Und ich habe auch noch ein weiteres Argument für einen umbau des bisherigen Weges: Ich möchte je Termin per Mouseover ein Popup ein/ausblenden können, in dem dann noch Rahmendaten des Termins eingeblendet (oder auch nachgeladen) werden. Ich fürchte, spätestens hier komme ich dann wieder mit den per JS eingeblendeten Terminen vs. der serverseitig eingesetzten Daten in die Bredouille.

            Pit

            1. Hallo Pit,

              ohne Ajax bist Du, was den Seiten-Neuaufbau angeht, auf den Browser angewiesen. Manche zeigen einen weißen Bildschirm während ein Request läuft, andere halten den alten Seiteninhalt fest bis die neue Seite fertig ist. Ist zumindest mein Eindruck.

              Eine flackerfreie Anzeige geht nur mit Ajax. Wenn Du von Ajax auf Full Page wechselst, machst Du meiner Meinung nach einen Schritt zurück. Andererseits tust Du denjenigen einen Gefallen, die JavaScript prinzipiell misstrauen und es abgeschaltet haben.

              Rolf

              --
              sumpsi - posui - clusi
              1. Hello,

                ohne Ajax bist Du, was den Seiten-Neuaufbau angeht, auf den Browser angewiesen. Manche zeigen einen weißen Bildschirm während ein Request läuft, andere halten den alten Seiteninhalt fest bis die neue Seite fertig ist. Ist zumindest mein Eindruck.

                Ich kenne keinen Browser mehr, der nicht den alten Inhalt hält, bis der neue zumindest mit Status 200 bestätigt wurde. Ob es dann flackert, hängt dann davon ab, ob ein Header für Content-Length gesendet wurde.

                Zunächst sollte die Seite ohne JavaScript/AJAX funktionieren. Als zusätzliches Mittel kann man das dann einbauen = vorwärtsgerichtete Verbesserung.

                Liebe Grüße
                Tom S.

                --
                Es gibt nichts Gutes, außer man tut es!
                Das Leben selbst ist der Sinn.
                1. Hi Tom,

                  Ich kenne keinen Browser mehr, der nicht den alten Inhalt hält, bis der neue zumindest mit Status 200 bestätigt wurde. Ob es dann flackert, hängt dann davon ab, ob ein Header für Content-Length gesendet wurde.

                  Habe verschiedene Seiten dieses themas gelesen, aber wirklich erklärt wird das nirgends. Was da rein soll und welchen Effekt das hat...?

                  Zunächst sollte die Seite ohne JavaScript/AJAX funktionieren. Als zusätzliches Mittel kann man das dann einbauen = vorwärtsgerichtete Verbesserung.

                  Naja, ziemlich puristische Einstellung. Ich glaube, mehr als das halbe Netz funktioniert ohne JS nicht.

                  Pit

                  1. Hello,

                    Ich kenne keinen Browser mehr, der nicht den alten Inhalt hält, bis der neue zumindest mit Status 200 bestätigt wurde. Ob es dann flackert, hängt dann davon ab, ob ein Header für Content-Length gesendet wurde.

                    Habe verschiedene Seiten dieses themas gelesen, aber wirklich erklärt wird das nirgends.

                    Wenn Du nichts dagegen tust, setzt der Webserver diese Header üblicherweise automatisch. Kannst Du dir mit der F12-Taste bei den meisten Browsern angucken.

                    Zunächst sollte die Seite ohne JavaScript/AJAX funktionieren. Als zusätzliches Mittel kann man das dann einbauen = vorwärtsgerichtete Verbesserung.

                    Naja, ziemlich puristische Einstellung. Ich glaube, mehr als das halbe Netz funktioniert ohne JS nicht.

                    Das ist wirklich traurig :-(

                    Liebe Grüße
                    Tom S.

                    --
                    Es gibt nichts Gutes, außer man tut es!
                    Das Leben selbst ist der Sinn.
                  2. Hallo

                    Zunächst sollte die Seite ohne JavaScript/AJAX funktionieren. Als zusätzliches Mittel kann man das dann einbauen = vorwärtsgerichtete Verbesserung.

                    Naja, ziemlich puristische Einstellung. Ich glaube, mehr als das halbe Netz funktioniert ohne JS nicht.

                    Weit mehr als die Hälfte davon könnte auch ohne JS funktionieren und wird mit JS einfach kaputtgemacht. Warum? Weil's geht.

                    Tschö, Auge

                    --
                    Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
                    Toller Dampf voraus von Terry Pratchett
    2. Hi dedlfix,

      Die einzige Möglichkeit, ohne Javascript eine Positionierung innerhalb einer Seite vorzunehmen, ist ein seiteninterner Verweis, der beim Seitenladen angesprungen wird.

      Mir gehts nicht darum, komplett auf JS zu verzichten. Ich merke nur, dass ich auf die eingangs beschriebene Weise doch stark an meine JS-Grenzen stoße. Das bedeutet, dass selbst wenn ich es hin bekomme, ich es nicht mehr supporten könnte, wenn mal aus irgendwelchen Gründen ein Browser darauf verzichtet, seine JS-Arbeit zu verrichten.

      Deshalb würde ich den JS-Einsatz beim Einsatz und Edit der Daten gerne etwas herunterfahren. Leider finde ich selber den Request plus Ansprung eines seiteninternen Verweises nicht so schön. Schön fände ich, wenn beim Request wenigstens nicht zwischenzeitlich die Seite komplett weg wäre. Ich dachte, man könnte ggf. per Iframe oder ähnlicher Technik nur einen Teil der Seite austauschen…

      Pit

      1. Hallo Pit,

        per iframe eher nicht, weil Du dann deine Seite aus iframes zusammensetzen musst und jeder einzelne davon beim Laden einen Webrequest auslöst.

        Du könntest es aber so versuchen, dass Du das HTML-Fragment, das auszutauschen ist, am Server als String erzeugst und dein JavaScript dieses Fragment einfach in den zu aktualisierenden Container deiner Seite einsetzt (JQuery html() oder innerHTML Property des DOM). Mit jQuery müsste das sogar per .load machbar sein. Kritisch sind dann nur Events in diesem Bereich, da solltest Du keine expliziten Registrierungen in austauschbaren Bereichen machen, sondern alle Handler außerhalb registrieren und die Events behandeln, wenn sie per bubbling vorbeikommen.

        Rolf

        --
        sumpsi - posui - clusi
        1. Hallo Rolf,

          Container deiner Seite einsetzt (JQuery html() oder innerHTML Property des DOM). Mit jQuery müsste das sogar per .load machbar sein.

          Ja, so ähnlich mache ich das auch.

          Kritisch sind dann nur Events in diesem Bereich, da solltest Du keine expliziten Registrierungen in austauschbaren Bereichen machen, sondern alle Handler außerhalb registrieren und die Events behandeln, wenn sie per bubbling vorbeikommen.

          Irgendwie wird mir die serverbasierte Lösung zunehmend sympathischer. 😉

          Pit