nicht angemeldet dedlfix
dedlfix
dedlfix
Felix Riesterer
Camping_RIDER
Tabellenkalk
JürgenB
Felix Riesterer
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
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
Yesgeht der Browser zu diesem URL, mitNohingegen 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.
Sowas sollte gar nicht erst gegeben sein: Daten verändernde Aktionen mit GET-Request abzuschicken,
In meinen Anwendungen ist HTTP transparent. MFG
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.
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
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.
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.
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
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
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
Hallo,
und gute Privatdetektive sind unsichtbar, aber keineswegs durchsichtig 😀
Gruß
Jürgen
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
Lieber pl,
Gegeben ist ein Link
<a href="?delete=123" onClick="return confirm('Eintrag löschen?')". Was passiert ist klar, mitYesgeht der Browser zu diesem URL, mitNohingegen 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.