pl: Frage zum Wiki-Artikel „Eigene_modale_Dialogfenster“

problematische Seite

Gegeben ist ein Link <a href="?delete=123" onClick="return confirm('Eintrag löschen?')". Was passiert ist klar, mit Yes geht der Browser zu diesem URL, mit No hingegen nicht. Wie würde das denn mit dem im Artikel beschriebenen myConfirm() aussehen? Vermutlich ein bischen komplizierter aber funktional hoffentlich genauso? MFG

  1. problematische Seite

    Tach!

    Gegeben ist ein Link <a href="?delete=123" onClick="return confirm('Eintrag löschen?')".

    Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken, und nur Javascript kann verhindern, dem Link ungewollt zu folgen.

    Was passiert ist klar, mit Yes geht der Browser zu diesem URL, mit No hingegen nicht. Wie würde das denn mit dem im Artikel beschriebenen myConfirm() aussehen? Vermutlich ein bischen komplizierter aber funktional hoffentlich genauso?

    Aber nehmen wir mal der Anwendungsfall wäre ein sinnvoller, dann müsste man den Eventhandler generell abbrechen und im OK-Callback die eigentliche Aktion auslösen.

    dedlfix.

    1. problematische Seite

      Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken,

      In meinen Anwendungen ist HTTP transparent. MFG

      1. problematische Seite

        Tach!

        Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken,

        In meinen Anwendungen ist HTTP transparent.

        Und, was konkret soll das heißen?

        Jedenfalls interessieren sich Bots üblicherweise nicht für Javascript und auch nicht wie "deine Anwendungen" arbeiten. Die schicken einfach mal Requests zu allen Links, die sie finden können.

        Im Wiki und in diesem Forum geht es auch nicht um "deine Anwendungen", weswegen die Warnungen zu etwas, das ungewollt Daten löschen kann, durchaus angebracht sind.

        dedlfix.

        1. problematische Seite

          Tach!

          Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken,

          In meinen Anwendungen ist HTTP transparent.

          Und, was konkret soll das heißen?

          Transparent heißt durchsichtig. Man kann auch sagen unsichtbar. MFG

          1. problematische Seite

            Tach!

            Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken,

            In meinen Anwendungen ist HTTP transparent.

            Und, was konkret soll das heißen?

            Transparent heißt durchsichtig. Man kann auch sagen unsichtbar.

            Die Bedeutung des Wortes ist mir klar, nur nicht, wie eine serverseitige Anwendung verhindert, das Bots und andere Automaten simplen Links folgen.

            dedlfix.

            1. problematische Seite

              Lieber dedlfix,

              Die Bedeutung des Wortes ist mir klar, nur nicht, wie eine serverseitige Anwendung verhindert, das Bots und andere Automaten simplen Links folgen.

              vielleicht meint @pl ja auch serverless...? Ist das nicht das neue Buzzword schlechthin?

              Liebe Grüße,

              Felix Riesterer.

            2. problematische Seite

              Die Bedeutung des Wortes ist mir klar, nur nicht, wie eine serverseitige Anwendung verhindert, das Bots und andere Automaten simplen Links folgen.

              Das ist ja auch nicht Sache der Anwendung. MFG

          2. problematische Seite

            Aloha ;)

            In meinen Anwendungen ist HTTP transparent.

            Und, was konkret soll das heißen?

            Transparent heißt durchsichtig. Man kann auch sagen unsichtbar. MFG

            Transparente Strukturen sind also unsichtbare Strukturen?

            Synonyme sind nicht in jeder möglichen Bedeutung synonym.

            Ich schätze daher, dass dein HTTP genauso wenig transparent ist wie transparente Strukturen unsichtbar sind. Vielleicht versuchst du folgerichtiger Weise einfach im Detail zu erläutern, was du mit dem Begriff meinst, den du da in den Raum wirfst.

            Grüße,

            RIDER

            -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

            # Twitter # Steam # YouTube # Self-Wiki #

            Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          3. problematische Seite

            Hallo,

            Transparent heißt durchsichtig. Man kann auch sagen unsichtbar.

            Durchsichtig und unsichtbar sind zwei unterschiedliche Konzepte:
            Eine Fensterscheibe ist durchsichtig aber nicht unsichtbar. Die meisten Gase sind unsichtbar, aber man spricht nicht davon, dass sie transparent sind.

            Gruß
            Kalk

            1. problematische Seite

              Hallo,

              und gute Privatdetektive sind unsichtbar, aber keineswegs durchsichtig 😀

              Gruß
              Jürgen

            2. problematische Seite

              Hallo,

              Transparent heißt durchsichtig. Man kann auch sagen unsichtbar.

              Durchsichtig und unsichtbar sind zwei unterschiedliche Konzepte:

              Nein. Transparenz beschreibt beides und gerade in der IT/TK gibt es keinen treffenderen Begriff. Genauso wie bei einem Telefongespräch, wo die Physik der Verbindung letztendlich keine Rolle mehr spielt: Denn Teilnehmern ist es nicht nur egal ob ihre Kommunikation über Glasfaser, Kupfer oder Funk abgewickelt wird, sie bekommen das gar nicht mit und müssen sich auch gar nicht darum kümmern.

              Genauso also ist das bei einer Client/Server Anwendung: Zwischen Client und Server sind höchstens austauschbare Layer. Das ganze handwerkliche Geschick beim Programmieren von Webanwendungen besteht darin, die serverseitige Logik samt Daten so am Client zugänglich zu machen, daß der Anwender meint er hätte eine Desktopanwendung vor sich. Und je abstrakter die dazwischenliegenden Schichtenmodelle definiert sind, desto transparenter ist der gesamte Transportlayer und umso besser gelingt die programmiertechnische Umsetzung.

              MFG

  2. problematische Seite

    Lieber pl,

    Gegeben ist ein Link <a href="?delete=123" onClick="return confirm('Eintrag löschen?')". Was passiert ist klar, mit Yes geht der Browser zu diesem URL, mit No hingegen nicht.

    dass soetwas Mist ist, hat @dedlfix ja schon korrekt angemerkt.

    Wie würde das denn mit dem im Artikel beschriebenen myConfirm() aussehen? Vermutlich ein bischen komplizierter aber funktional hoffentlich genauso?

    myConfirm( "Eintrag löschen?", function () { location.href = "?delete=123"; } );

    Besser wäre aber, wenn der Löschvorgang durch POST erfolgt. Da kann man dann anstelle von location.href einen echten Ajax-Call mit POST-Methode verwenden. Was Du in die OK-Callback-Funktion schreibst, ist ja völlig egal.

    Liebe Grüße,

    Felix Riesterer.