nicht angemeldet
Rolf B
Matthias Apsel
MudGuard
Tabellenkalk
MudGuard
Der Martin
JürgenB
Der Martin
Rolf B
JürgenB
Christian Kruse
Christian Kruse
Hallo,
ich mag die kleinen Popups nicht, die über
<A HREF="delete.php?id=1" onclick="return confirm('Wirklich löschen?')">löschen</A>
erzeugt werden.
Nun gibt es ja jede Menge Scripte, die sehr schöne Popups erzeugen. Aber mir fällt auf, dass (bisher keines, was ich kenne) den Link selber ausführt. Ich muß dann über Javascript eine Weiterleitung auf den Link machen mitsamt seinen Parametern.
Beim obigen Beispiel gefällt mir, dass er sozusagen in den HTML-Fließtext eingeschoben werden kann, das JS hält aber die Fortführung nur an und beim Bestätigen gehts weiter zum Link.
Wenn ich z.b. ein Jquery-Plugin nutze, ist es viel komplizierer:
<a class='confirm' href='#'>delete</a>
<script type="text/javascript">
jconfirm.defaults = {
title: 'Bestätigung',
useBootstrap: false,
};
$('.confirm').on('click', function(){
$.confirm({
title: 'Achtung:',
icon: 'fa fa-warning',
type: 'orange',
titleClass: 'confirm_title',
content: '<div class="confirm_content_klein"></div>' +
'<div class="confirm_content"><br>Wirklich löschen?</div>',
autoClose: 'Abbrechen|80000',
width :'auto',
buttons: {
OK: function () {
window.location.href = href="delete.php?id=1";
},
Abbrechen: function () {
// $.alert('Canceled!');
}
}
});
});
</script>
Gibt es nicht eine geschickte Möglichkeit, diesen Jquery-Code dergestalt auszulagern, dass ich ihn leichter ansprechen kann? Ich habe den jetzt schon in eine php-Funktion gepackt, die ich dann über einen php-Funktionsaufruf mitsamt "content" und "Linkadresse" aufrufe, aber das ist trotzdem von der Bequemlichkeit des obigen Beispiels meilenweit entfernt.
Ich durchsuche nämlich derzeit meine Scripte und es ist fast unmöglich, den Code überall auszutauschen, wenn das Austauschen so kompliziert ist.
Hat jemand eine clevere Idee, wie es einfacher ginge?
Pit
Hallo Pit,
clevere Idee, wie es einfacher ginge?
Ja, lies nochmal genau die Anleitung von jquery-confirm durch. Konkret: Hier
this.$target.attr('href') automatisch an das href-Attribut des <a> Elements herankommtIch bin von der Funktionalität auch nicht so recht überzeugt. Man kann zwar immerhin mit Tab und ENTER die Buttons erreichen und bedienen, aber der Tab-Fokus bleibt nicht im Dialog.
Rolf
Hallo Rolf,
Danke für Deine Antwort, die ist sehr hilfreich!
clevere Idee, wie es einfacher ginge?
Ja, lies nochmal genau die Anleitung von jquery-confirm durch. Konkret: Hier
Oh, Du hast Recht. Das hatte ich doch glatt komplett überlesen! Das ist (fast) genau das, was ich suche! 😀
- Du musst keinen click-Handler schreiben, du kannst $("a").confirm(...) aufrufen. Er registriert sich dann selbst auf den Klick.
Ich habs ausprobiert und - ja - es funktioniert.
- Wenn Du keine Buttons angibst, baut jquery-confirm selbst einen okay- und einen cancel-button und folgt bei okay selbst dem Link. Das mag für Dich unpassend sein, aber es gibt da auch ein Beispiel wie man mit
this.$target.attr('href')automatisch an das href-Attribut des <a> Elements herankommt
Warum meinst Du, es sei für mich unpassend? Ist doch ansich gen au das, was ich nachgefragt habe... bis auf eine Sache noch, nämlich...
- Ob Du in dieser Variante eigenen content angeben kannst, musst Du ausprobieren. Ich finde die Doku unzuzeichend, und es ist auch eine Fehlkonzeption, HTML für den Dialoginhalt als String zu erwarten. Dafür gibt's Template-Möglichkeiten.
Genau die meine ich... Es wäre sehr hilfreich, wenn ich über den Link auch Content diurchschleifen könnte. Aber ich wüßte nicht, wie???
Ich bin von der Funktionalität auch nicht so recht überzeugt. Man kann zwar immerhin mit Tab und ENTER die Buttons erreichen und bedienen, aber der Tab-Fokus bleibt nicht im Dialog.
Hatte ich auch schon gesehen. Aber immerhin kannst Du hier eien Tastenabfrage einbeziehen... besser als nichts. Und ansonsten gefällt mir das Plugin recht gut.
Wenn ich jetzt noch irgendwie im Link oder im a-Attribut content durchschleifen könnte, wärs für eminen Einsatz gut geeignet.
Gruß, Pit
Hallo Rolf,
Wenn ich jetzt noch irgendwie im Link oder im a-Attribut content durchschleifen könnte, wärs für eminen Einsatz gut geeignet.
Gruß, Pit
Nun ist es mir gelungen, eigenen Content durchzuschleifen:
<a class="example2-1-1" href="http://twitter.com/craftpip" data-Content="Wollen Sie wirklich zu Twitter?">Goto twitter</a>
$('.example2-1-1').confirm({
content: $(this).data( "Content" ),
width :'auto'
});
Pit
Hallo Pit,
hast Du's mal probiert, die content: $(this)... Zeile im Init-Objekt einfach wegzulassen? Ich hab da so einen Verdacht...
Und im Quellcode steht's drin:
if($this.attr('data-title'))
jcOption['title'] = $this.attr('data-title');
if($this.attr('data-content'))
jcOption['content'] = $this.attr('data-content');
Rolf
Hallo Pit,
hast Du's mal probiert, die content: $(this)... Zeile im Init-Objekt einfach wegzulassen? Ich hab da so einen Verdacht...
Und im Quellcode steht's drin:
if($this.attr('data-title')) jcOption['title'] = $this.attr('data-title'); if($this.attr('data-content')) jcOption['content'] = $this.attr('data-content');
Soll heißen, ich könnte einfach über das Attribut "data-content" einen content durchschleifen und der wird "von Hause aus" bereits ausgewertet?
Wenns so ist, dann erstens Danke an Dich fürs herausfinden... und zweitens ist das dann schlicht nicht dokumentiert 😕
Gruß, Pit
Hallo Pit,
stimmt, die Doku ist - wie bei vielen open-source Projekten - Käse. Der/die Autor(in) weiß doch was er/sie gemacht hat. Es dann auch noch ordentlich aufzuschreiben macht keinen Spaß. Überhaupt nicht. Dokumentieren macht nie Spaß. Darum ist Doku der schwächste Teil eines Systems. Es sei denn, man hat einen sehr motivierten oder disziplinierten Autor. Oder massiven Zwang durch irgendwelche Erbsenzähler.
Rolf
Hallo,
ich mag die kleinen Popups nicht, die über
<A HREF="delete.php?id=1" onclick="return confirm('Wirklich löschen?')">löschen</A>erzeugt werden.
Warum denn nicht? Einfacher und zweckmäßiger gehts doch gar nicht. Wobei ich mal hier im Forum gelesen habe daß Löschvorgänge nicht per GET gemacht werden sollen.
MFG
Hallo pl,
Wobei ich mal hier im Forum gelesen habe daß Löschvorgänge nicht per GET gemacht werden sollen.
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
Bis demnächst
Matthias
Hi,
Wobei ich mal hier im Forum gelesen habe daß Löschvorgänge nicht per GET gemacht werden sollen.
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
oder auch mal ein (über-)eifriger Browser, der Prefetch für die verlinkten Seite macht …
cu,
Andreas a/k/a MudGuard
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
Es gibt Suchmaschinen die machen sogar LOG-Requests. MFG
Hallo pl,
Wobei ich mal hier im Forum gelesen habe daß Löschvorgänge nicht per GET gemacht werden sollen.
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
Hallo Mathias,
Suchmaschinen haben auf dieses Projekt keinen Zugriff. Und selbst wenn, dann flögen sie wieder raus, weil sie keinen Account hätten.
Gruß, Pit
Hallo,
Suchmaschinen haben auf dieses Projekt keinen Zugriff. Und selbst wenn, [...]
Es geht aber nicht (nur) um dieses Projekt! Und selbst wenn: wer weiß denn, ob sich die Zugangs-Policy nicht auch mal ändert, oder die Code-Basis mal für ein weiteres, offeneres Projekt verwendet werden soll...
Gruß
Kalk
Hi Kalk,
Und selbst wenn: wer weiß denn...
Ich 😉
Nein, ok. Ich verstehe das schon, finde aber auch, dass derjenige, der Code für ein anderes Projekt übernimmt, diesen an seine Voraussetzungen und Umgebung anpassen sollte.
Es ist doch klar, dass ich z.b. anders programmieren kann, wenn ich etwas für ein Intranet mit abgestecktem Personenkreis erstelle, als wenn ich dasselbe fürs Internet mit unbegrenztem und unbekanntem Personenkreis erstelle.
Gruß, Pit
Hi,
Es ist doch klar, dass ich z.b. anders programmieren kann, wenn ich etwas für ein Intranet mit abgestecktem Personenkreis erstelle, als wenn ich dasselbe fürs Internet mit unbegrenztem und unbekanntem Personenkreis erstelle.
Viele "Hacker"-Angriffe erfolgen von innen (unzufriedener/gekündigter Mitarbeiter ...)
cu,
Andreas a/k/a MudGuard
Hallo,
Es ist doch klar, dass ich z.b. anders programmieren kann, wenn ich etwas für ein Intranet mit abgestecktem Personenkreis erstelle, als wenn ich dasselbe fürs Internet mit unbegrenztem und unbekanntem Personenkreis erstelle.
Viele "Hacker"-Angriffe erfolgen von innen (unzufriedener/gekündigter Mitarbeiter ...)
und Admins, die ihre Privilegien zum Abgreifen oder Manipulieren vertraulicher Daten missbrauchen, sind vermutlich auch keine Seltenheit.
Okay, das ist eine andere Situation, aber auch unter dem Oberbegriff "Angriff von innen".
Ciao,
Martin
Hallo Martin,
Okay, das ist eine andere Situation, aber auch unter dem Oberbegriff "Angriff von innen".
bei uns heißt „von innen“ ca. 10.000 teils öffentlich zugängliche Rechner und ca. 55.000 User, die alle potentielle WLAN- und VPN-User sind.
Gruß
Jürgen
Hallo JürgenB,
Okay, das ist eine andere Situation, aber auch unter dem Oberbegriff "Angriff von innen".
bei uns heißt „von innen“ ca. 10.000 teils öffentlich zugängliche Rechner und ca. 55.000 User, die alle potentielle WLAN- und VPN-User sind.
Wobei die Uni Gießen ja eindrucksvoll demonstriert hat, was da passieren kann. Komplette IT heruntergefahren, alle Endgeräte der User müssen neu aufgesetzt werden. Ein buchstäblich monate langer Ausfall.
„Hackerangriff: Viele Sicherheitsmaßnahmen in Praxis nicht angewandt“ – aber hey, die Admins lieber nicht konkurrenzfähig bezahlen, das spart Geld! 🤷♂️
Freundliche Grüße,
Christian Kruse
Hallo,
Okay, das ist eine andere Situation, aber auch unter dem Oberbegriff "Angriff von innen".
bei uns heißt „von innen“ ca. 10.000 teils öffentlich zugängliche Rechner und ca. 55.000 User, die alle potentielle WLAN- und VPN-User sind.
ja klar, je nach Art und Größe der Institution oder Firma kann "von innen" sehr unterschiedliche Dimensionen haben. Bei mir zuhause hieße "von innen" entweder, dass ein Eindringling an meinem PC rummacht, oder dass ein Nachbar mein WLAN gehackt hätte.
Ergänzung: Im ersten Fall wäre das kompromittierte Heimnetzwerk wohl noch mein kleinstes Problem; den zweiten Fall würde ich zumindest an den Protokollen meines WLAN-Routers erkennen und dann schleunigst die SSID und das Passwort ändern.
Ciao,
Martin
Hallo Andreas,
Viele "Hacker"-Angriffe erfolgen von innen (unzufriedener/gekündigter Mitarbeiter ...)
Das stimmt. Genauso, wie viele Ladendiebstähle von Mitarbeitern kommen. Vielleicht hatte ich bisher Glück, aber Du hast völlig Recht, ich werde das künftig (noch!) mehr berücksichtigen.
Pit
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
... und Suchmaschinen klicken auch Confirm-Dialoge? 😉
Pit
Hallo,
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden, weil die Gefahr besteht, das Suchmaschinen (oder Bösewichte) den Links folgen.
... und Suchmaschinen klicken auch Confirm-Dialoge? 😉
noch besser: Sie folgen unter Umständen direkt dem Link, ohne sich um Javascript zu kümmern, das sich darum rankt.
Ciao,
Martin
Hallo Martin,
noch besser: Sie folgen unter Umständen direkt dem Link, ohne sich um Javascript zu kümmern, das sich darum rankt.
Diese Gemeinen... 😕
Irgendwann klicken sie auch Buttons...oder füllen Formulare aus... Ihr werdet es sehen...
Hallo Pit,
noch besser: Sie folgen unter Umständen direkt dem Link, ohne sich um Javascript zu kümmern, das sich darum rankt.
Diese Gemeinen... 😕
Irgendwann klicken sie auch Buttons...oder füllen Formulare aus... Ihr werdet es sehen...
meines Wissens tun sie das schon längst. Was Spambots können, können auch die Bots von Suchmaschinen.
So long,
Martin
Hallo Matthias,
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden...
Nope. Sie DÜRFEN es nicht. Weil die Semantik des GET Requests Idempotenz beinhaltet. Was ein GET einmal liefert, liefert er immer. Darum darf man GET Requeste bedenkenlos cachen.
So ist das zumindest, wenn man das Web als statisches Gerank von Dokumenten ansieht. Natürlich gibt es GET Requeste auf URLs, die nicht immer das Gleiche liefern. Zeitabfragen zum Beispiel, oder ein GET auf https://forum.selfhtml.org/self.
Wichtig dabei ist aber: Die Veränderung der Response ist nicht diesem GET zuzuschreiben, sondern Einflüssen durch Dritte.
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Rolf
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Moderne Programiertechniken nutzen OOP, Design Patterns und Schichtenmodelle. Nach moderen Gesichtspunkten programmierte Webanwendungen kennen weder den Transportlayer noch die Requestmethode.
MFG
Hallo,
… Nach moderen Gesichtspunkten programmierte Webanwendungen kennen weder den Transportlayer noch die Requestmethode.
den Eindruck habe ich auch häufiger. 😀
Gruß
Jürgen
Hallo pl,
dein Beitrag klingt irgendwie wie das Techno-Babbel aus TV-Serien wie Scorpion…
Freundliche Grüße,
Christian Kruse
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Moderne Programiertechniken nutzen OOP, Design Patterns und Schichtenmodelle. Nach moderen Gesichtspunkten programmierte Webanwendungen kennen weder den Transportlayer noch die Requestmethode.
MFG
Als Ergänzung: Wie ein Request zu verarbeiten ist, darüber entscheidet nicht die Requestmethode sondern der Content-Type. Und ob ein Body gesendet wurde, wird auch nicht anhand der Requestmethode festgestellt sondern anhand Content-Length.
Dogmen wie Idempotents richten sich gegen moderne Programmiertechniken, gegen zweckmäßige Schichtenmodelle und letztendlich auch gegen OOP.
MFG
Hallo pl,
damit das hier nicht unwidersprochen stehen bleibt:
Als Ergänzung: Wie ein Request zu verarbeiten ist, darüber entscheidet nicht die Requestmethode sondern der Content-Type.
Nein. Wie ein Request zu verarbeiten ist, entscheidet die Programm-Logik. Ob bei einem Request ein Schreibzugriff stattfindet oder nicht sollte allerdings den gängigen Best Practices folgen; dass etwa und warum GET-Requests idempotent sein sollten, wurde des öfteren hier im Forum durchgekaut und erklärt.
Dogmen wie Idempotents richten sich gegen moderne Programmiertechniken, gegen zweckmäßige Schichtenmodelle und letztendlich auch gegen OOP.
Best practices wie Idempotenz sind die Basis für ein funktionierendes, kooperatives WWW.
Freundliche Grüße,
Christian Kruse
Hallo Rolf,
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Das Forum übrigens verstösst an einer Stelle (bewusst) gegen dieses Gebot: bei der serverseitigen Gelesen-Markierung. Die löst bei GET-Requests aus (und prüft auch, ob es ein prefetch ist und tut in dem Fall gar nichts).
Freundliche Grüße,
Christian Kruse
Hallo Christian,
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Das Forum übrigens verstösst an einer Stelle (bewusst) gegen dieses Gebot: bei der serverseitigen Gelesen-Markierung.
das ist wohl eine legitime und sehr sinnvolle Ausnahme von der Regel - aber selbst mit dieser Funktionalität als Nebenwirkung eines GET läuft bei jedem Request dasselbe ab und hat dasselbe Ergebnis. Einmal gelesen ist gelesen; 12mal gelesen ändert daran auch nichts.
Die löst bei
GET-Requests aus (und prüft auch, ob es ein prefetch ist und tut in dem Fall gar nichts).
Wie erkennt man denn Prefetch-Requests? Geben die sich durch bestimmte Header zu erkennen?
Ciao,
Martin
Hallo Martin,
Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen.
Das Forum übrigens verstösst an einer Stelle (bewusst) gegen dieses Gebot: bei der serverseitigen Gelesen-Markierung.
das ist wohl eine legitime und sehr sinnvolle Ausnahme von der Regel - aber selbst mit dieser Funktionalität als Nebenwirkung eines GET läuft bei jedem Request dasselbe ab und hat dasselbe Ergebnis. Einmal gelesen ist gelesen; 12mal gelesen ändert daran auch nichts.
Das ist erst dann richtig, wenn der Beitrag gelesen markiert wurde. Wenn ein Beitrag noch ungelesen ist, dann verändert der GET-Request den Status durchaus.
Die löst bei
GET-Requests aus (und prüft auch, ob es ein prefetch ist und tut in dem Fall gar nichts).Wie erkennt man denn Prefetch-Requests? Geben die sich durch bestimmte Header zu erkennen?
Ja. Verschiedene Browser-Versionen schicken verschiedene Header, aber im wesentlichen läuft es darauf hinaus: wenn einer der drei Header x-moz, x-purpose oder purpose geschickt wurde und den Wert preview oder prefetch enthält, ist es ein Prefetch-Request.
Ich war aber ungenau: Prefetch-Requests werden aber nur auf Seiten geschickt, die mit rel=prefetch oder via <link>-Element (z.B. <link rel="next">) referenziert wurden. Deshalb verwende ich in V5 diese Auszeichnungen nicht (mehr) und V5 hat diesen Check auch nicht mehr eingebaut, sondern markiert einfach jeden ungelesenen angefragen Beitrag als gelesen. Die Prüfung auf einen Prefetch-Requests war Teil von V4.
Freundliche Grüße,
Christian Kruse
Hallo Matthias,
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden...
Nope. Sie DÜRFEN es nicht. Weil die Semantik des GET Requests Idempotenz beinhaltet. Was ein GET einmal liefert, liefert er immer. Darum darf man GET Requeste bedenkenlos cachen.
WIKI:
Idempotenz ist eine Bezeichnung aus der Mathematik und Informatik. In der Mathematik bezeichnet man ein Objekt , das mit einer Verknüpfung die Eigenschaft hat, als idempotent bezüglich dieser Verknüpfung. Ein wichtiger Spezialfall sind idempotente Funktionen bezüglich der Hintereinanderausführung.
Letzteres betrifft also in OOP höchstens die Verkettung von Methoden. Die auch nur deswegen funktioniert weil der Return-Value die Instanz selber ist. Und auch dabei ist es unerheblich ob eine Methode diese Instanz verändert oder nicht.
Den Begriff der Idempotenz überhaupt in HTTP einzubringen halte ich für blödsinnig. Und eine Policy hat im Code auch nichts zu suchen.
MFG
Tach!
Idempotenz ist eine Bezeichnung aus der Mathematik und Informatik. In der Mathematik bezeichnet man ein Objekt , das mit einer Verknüpfung die Eigenschaft hat, als idempotent bezüglich dieser Verknüpfung. Ein wichtiger Spezialfall sind idempotente Funktionen bezüglich der Hintereinanderausführung.
In deinem Zitat fehlen Formeln. In der Form ist die Aussage entstellt und unverständlich. Der wichtigste Teil für den aktuellen Fall ist jedoch der folgende Satz, den du nicht zitiert hast.
"Analog dazu wird in der Informatik ein Stück Programmcode, das mehrfach hintereinander ausgeführt das gleiche Ergebnis wie bei einer einzigen Ausführung liefert, als idempotent bezeichnet."
Letzteres betrifft also in OOP [...]
OOP und andere Programmiertechniken stehen im vorliegenden Fall nicht zur Diskussion. Es geht um HTTP, ein Protokoll. Was dein privates Framework (vielleicht auch abseits von Standards) macht, ist dein Problem und begründet nicht pauschale Behauptungen zu "moderner Programmierung".
dedlfix.
Hallo pl,
(Edit: Ich habe mit diesem Beitrag angefangen, bevor Dedlfix gepostet hat)
ein Objekt, das mit einer Verknüpfung die Eigenschaft hat
da ist dir was beim Kopieren vom Clipboard gerutscht. Hier vollständig:
ein Objekt, das mit einer Verknüpfung $$\circ$$ die Eigenschaft $$a \circ a = a$$ hat
Konkret erläutert die Wikipedia auch für den Objekttyp "Funktion", dass eine idempotente Funktion bezüglich der Verkettung von Funktionen die Eigenschaft $$f(f(a)) = f(a)$$ hat.
Im Falle eines Web-Requests ist $$a$$ der Systemzustand des Servers, und $$f$$ ein HTTP Request. $$f(a)$$ ist der Systemzustand nach Verarbeitung des Requests. Für einen idempotente Request bedeutet $$f(f(a)) = f(a)$$, dass der Systemzustand des Servers nach zweimaliger Abarbeitung des Requests der gleiche ist wie nach einmaliger Abarbeitung.
Und das heißt: Ich habe zuvor Blödsinn geredet und etwas gelernt. Idempotent ≠ Identisch. Idempotenz bedeutet nicht, dass die Response von $$f(a)$$ die gleiche sein muss wie die von $$f(f(a))$$, denn diese Responses werden basierend auf unterschiedlichen Systemzuständen $$a$$ und $$a'$$ erzeugt. Insofern ist auch Christian drauf reingefallen, denn danach ist sein GET, der eine Gelesen-Markierung setzt, idempotent.
Für Christian ist es wichtig, dass $$f$$ sich je nach Request-Art (Preview oder nicht) unterschiedlich verhält. Aber auch da ist er idempotent, denn zwei Preview-GETs sollten das Forum in den gleichen Zustand versetzen wie einer. Idealerweise ist dieser Preview-GET nicht nur idempotent, sondern auch identisch, d.h. $$f_p(a) = a$$ - der Zustand des Forums verändert sich nicht.
Das gilt nicht für POSTs. $$p(p(a)) \ne p(a)$$ ist durchaus zugelassen. Natürlich darf ein POST gelegentlich mal idempotent sein, z.B. wenn zwei Posts zu schnell aufeinander folgen, darf der 2. Post einen Flooding-Error liefern und das Forum unverändert lassen.
Danke für die Anregung zum Nachlesen.
Du siehst übrigens, dass Idempotenz im HTTP Protokoll durchaus einen Platz hat. De vordefinierten HTTP Methoden haben Semantik. Man darf sie nicht straflos ignorieren.
Rolf
Hallo Rolf,
Insofern ist auch Christian drauf reingefallen, denn danach ist sein GET, der eine Gelesen-Markierung setzt, idempotent.
Nein, du hast nur nicht genau genug gelesen 😉 ich habe nicht behauptet, die Implementation der Gelesen-Markierung sei nicht idempotent. Ich schrieb, ich setze mich bewusst über die best practice „Schreibvorgänge darf ein GET höchstens in Caches oder Logfiles auslösen“ hinweg.
Ob die Implementation idempotent ist oder nicht, darüber hatte ich gar nicht nachgedacht, denn Idempotenz spielt in meinem Alltag nur eine sehr kleine Rolle.
Freundliche Grüße,
Christian Kruse
Hallo Christian,
denn Idempotenz spielt in meinem Alltag nur eine sehr kleine Rolle.
solange man nicht zwei entscheidende Buchstaben "vergisst". ;-)
*scnr*, eine schöne Steilvorlage,
Martin
Hallo Matthias,
Alle Vorgänge, die Veränderungen an Daten zur Folge haben, sollten nicht per GET gemacht werden...
Nope. Sie DÜRFEN es nicht. Weil die Semantik des GET Requests Idempotenz beinhaltet. Was ein GET einmal liefert, liefert er immer. Darum darf man GET Requeste bedenkenlos cachen.
WIKI:
Idempotenz ist eine Bezeichnung aus der Mathematik und Informatik. In der Mathematik bezeichnet man ein Objekt , das mit einer Verknüpfung die Eigenschaft hat, als idempotent bezüglich dieser Verknüpfung. Ein wichtiger Spezialfall sind idempotente Funktionen bezüglich der Hintereinanderausführung.
Letzteres betrifft also in OOP höchstens die Verkettung von Methoden. Die auch nur deswegen funktioniert weil der Return-Value die Instanz selber ist. Und auch dabei ist es unerheblich ob eine Methode diese Instanz verändert oder nicht.
Wobei eine Verkettung von Methoden gerade dann erst richtig interessant wird, wenn die in der Instanz referenzierten Daten verändert werden. Z.B. beim Auslösen einer Bestellung und beim Leeren des Warenkorb. Bei solchen Verkettungen bleibt man innerhalb einundderselben Klasse.
Den Begriff der Idempotenz überhaupt in HTTP einzubringen halte ich für blödsinnig.
Weil es da nichts zu verketten gibt. Der Datenaustausch zwischen Datenhaltungsschicht und Anwendung hat über klar definierte Schnittstellen zu erfolgen, was die Layer einmal transparent macht und zum Anderen aber auch voneinander abgrenzt. Derartige Abläufe sind nicht nur klassenübergreifend sondern auch systemübergreifend.
MFG
Hallo pl,
Weil es da nichts zu verketten gibt
Verketten kann man auf vielerlei Art. Siehe meinen Beitrag von 12:21.
Rolf