Druckbare Version
Bin dafür die Forum Kategorie
HTML und Markupsprachen Forum
XML, Javascript, CSS, XSL, XSLT, SVG
um Ajax zu erweitern.
Ajax Postings in der Kategorie Scriptsprachen halte ich für nicht so passend,
da Ajax (so weit ich das verstanden habe) auf JS basiert.
http://www.mrunix.de/forums/showthread.php?t=49833
Was haltet ihr davon?
Irgendwo müssen die Ajax Postings rein?!
Hallo,
Danke, guter Tipp. Ist schon drin.
Viele Grüße
Eicke
... dann habt ihr da bald alles mit php aufgeweicht. :)
Ajax ohne php oder eine andere Scriptsprache kann ich mir im Moment nicht vorstellen.
so long,
BlueJay
Sehe ich wenig Sinn, Ajax sind 2 Seiten Lernstoff der Rest ist Javascript bei Webdesign.
Mir ist bisher immer noch Schleierhaft wie man ein Buch mit mehr als 100 Seiten darüber Schreiben kann :confused:
Wenn man die Kategorie erweitert sollte JSON verwendet werden und nach Scriptsprachen verlegt werden.
Somit kommen auch Sprachen wie Perl/Python/Rubi/PHP/C/C++/Java/ActionScript mit in diese Kategorie.
Man Spricht zwar Überall von Ajax aber JSON ist Eigentlich der Korrekte Ausdruck hierfür.
http://www.json.org Nicht umsonst heißen z.B. die Funktionen unter PHP json_encode() json_decode() ;)
Was ist denn wohl literarisch wertvoller?Zitat:
Zitat von undefined
Schiller: Die Glocke
oder:
Loch gebuddelt.
Bronze rin,
Glocke raus,
bim, bim,bim!
:D BlueJay
Als Poet oder Lyriker Schiller, aber ich als Programmierer? - Buddeln - oder Wie Messner schon sagte, der Weg ist das Ziel :DZitat:
Zitat von BlueJay
Hmmm. Dem kann ich nicht zustimmen. JSON ist ein Datenübertragungsformat, alternativ zu XML (von dem AJAX seinen letzten Buchstaben hat). Man kann auch stinknormalen Text oder sonstwas verwenden.Zitat:
Zitat von undefined
Für mich ist der Witz an Ajax, dass im Hintergrund ein zweiter "Browser" aufgemacht wird, der dann mit dem Server kommuniziert. Das ist hauptsächlich JS-Funktionalität. Und die Interpretation nebst Bildschirmupdate rei findet ebenfalls in JS statt.
Dass auf dem Server sinnvollerweise - aber nicht mal notwendigerweise - irgendwas dynamisches passiert, ist eine andere Sache. Und ob das PHP, Perl oder sonstwas ist, ist ja auch völlig offen.
Und kann man über AJAX einiges schreiben? Ich meine schon. Alleine die Themen Brwoserunabhängigkeit sind schon kapitelfüllend. Und die Themen "bookmarking" und "Browser-back". Und Transakationssicherheit, v.a. bei asynchronen Calls (A<jax). Und wie implementiere ich wartbaren Code, RPC-Konzepte? Libraries. Bei all diesen Themen überwiegen meiner Einschätzug nach auch die Herausforderungen auf Client-Seite (->"JS").
Es geht hier ja auch nur um die Schnittstelle und nicht um das bischen JS beim Webdesign, mal davon abgesehen das man auch mit Java/Flash auf diese Schnittstelle zugreifen kann deshalb mein für spruch zu JSON. Du schreibst beim Webdesign einmal eine Klasse und das wars, daher auch mein Statement darüber warum man hier ein über 100 Seiten Buch schreiben kann. JSON gibt es schon seit XUL mit dem Unterschied das im Moment ein riesen heib darum gemacht wird. Wobei ein Thema hierbei völlig im Hintergund steht. JSON ist im Moment noch nicht sicher. Du kannst so gut wie alles über diese Schnittstelle senden. Und das liegt nun mal nicht auf JS Ebene sondern auf Server Ebene wie du das Behandelst.
Sorry, aber ich kann mich deiner Meinung immer noch nicht anschließen.Zitat:
Zitat von undefined
"Bißchen Webdesign" - schau dir mal moderne Seiten an: seitenweise JS-Code und/oder imortiertierte JS-Libraries! (Und ich würde das Aktualisieren des Seiteninhalts auch nicht als "Webdesign" bezeichnen)
XUL: Ist das nicht was FF-spezifisches? Gibt es das auch beim IE?
"JSON ist nicht sicher": Ich dachte, JSON ist ein Daten-Format, welches von JS von Hause aus und von anderen Sprachen per Erweiterung erzeugt/verarbeitet werden kann. Kann man sagen, dass ein Datenformat nicht sicher ist? Sicher muss doch der Code sein, der die Daten interpretiert. Und warum soll das dafür sprechen, dass hier die "AJAX"-Abteilung "JSON"-Abteilung genannt werden soll? (Nochmals: JSON ist eine Alternative für den Datenaustausch bei der asynchronen Kommunikation zw. Browser und Server). Wiedersprichst du dir nicht selber?
Ja XUL ist eine Mozilla Geschichte und von hier stammt das XMLHttpRequest Object. Was für die Asyncron Verbindung von Json zum Server zuständig ist. ich weis jetz auch nicht was du mit Wiedersprechen meinst.
Der Javascript Code für eine JSON Schnittstelle zu erstellen ist eine ein DIN A4 Seite Klasse mehr nicht. Alle andere ist ganz Normales Javascript und hat mit der Schnittstelle oder wie manche sagen Ajax nicht mehr zu tun. Ich habe mir dafür einmal eine Klasse geschrieben und seit dem war es gut.
Was die Sicherheit betrifft ja - das ist eine Serversprachen Angelegenheit deshalb auch meine Aussage zu JSON weil hier nämlich die Schwachstellen liegen. Auf Browser Seite nützt es dir wenig. Sowas must du mit PERL/Python/PHP oder anderen CGI fähigen Schnittstellen machen.
Ich kann deiner Argumentation nicht folgen. Warum sollte denn nun deiner Meinung nach der Themenbereich "AJAX" in "JSON" umbenannt werden?Zitat:
Zitat von undefined
Aber ist eigentlich auch egal. Es existiert schließlich bereits und für fast alle hier im Forum ist es auch ok mit diesem Titel.