IE und Ajax

[Markus42]

Schönen Nachmittag zusammen.
Immer schön wenn man Code im Ff ausprobiert und wenn man fertig ist mit IE testet und erstmal gar nichts geht. >.<
Naja hab jetzt schon den Großteil behoben aber etwas ärgert mich immer noch:
Ich hab in meinem Code 2 Ajax Requests. Das eine Funktioniert ganz wie erwartet in FF und IE aber beim anderen schickt IE das Request nicht weg oder kann den Rückgabe wert nicht interpretieren. (originalRequest.responseText ist leer)

Hier das Request:

  
function getl(lvo,lna,idS) {  
  var myAjax = new Ajax.Request(  
    "getl.php",  
    { method: 'get', parameters: 'v='+lvo+'&n='+lna+'&id='+idS+'' ,onComplete: live }  
  );  
}  

Alle variablen bei parameters sind belegt.
und die live funktion:

  
function live( originalRequest ) {  
 var lol = originalRequest.responseText;  
 if (lol == "")  
  {  
  return 0;  
  }  
        eval(originalRequest.responseText);  
       }  

Wie gesagt in FF gehts ohne Probleme.

Die php Datei enthält folgendes:

  
<?php  
include ("db.php");  
$id = $_GET['id'];  
$ov = $_GET['v'];  
$on = $_GET['n'];  
$abfrage = "SELECT * FROM Spiele WHERE ID = '$id'";  
  
$ergebnis = mysql_query($abfrage);  
  
while($row = mysql_fetch_object($ergebnis))  
  
   {  
 $amzug = "$row->amzug";  
 $lv = "$row->lvon";  
 $ln = "$row->lnach";  
   }  
if ($ov == $lv and $on == $ln)  
 {  
 }  
else  
 {  
 printf("vo = %s;\n",json_encode($lv));  
   printf("na = %s;\n",json_encode($ln));  
 }  
?>  

Firefox hab ich die neueste Version und IE 7.0.6...

Ich hoffe ihr könnt mir helfen.

mfg

Markus

[ChrisB]

Hi,

Ich hab in meinem Code 2 Ajax Requests.

Und die Unterschiede zwischen beiden sind?

Das eine Funktioniert ganz wie erwartet in FF und IE aber beim anderen schickt IE das Request nicht weg oder kann den Rückgabe wert nicht interpretieren.

Erst mal das "oder" eliminieren.

Deinen Request schickst du wohl asynchron ab, nehme ich an - welches Framework du da benutzt, sagst du ja dummerweise nicht dazu.

Dann muss der IE ihn ja schon mal "abschicken" - denn sonst kaeme die Handlerfunktion fuer onComplete ja wohl gar nicht erst zur Ausfuehrung.

Die php Datei enthält folgendes:

Liefert es das korrekte Ergebnis, wenn es "manuell" aufgerufen wird?

Kommt der Request vom IE in der richtigen Form beim Server an? (Logfiles)

MfG ChrisB

[Markus42]

Hi,
Und die Unterschiede zwischen beiden sind?

Hallo,

das das funktioniert benutzt "post" und rate mal: Ja wenn ich das andere auch mit post übergebe funktioniert es auch im IE. :P
Würd mich zwar jetzt interessieren, warum das mit get nicht geht, aber ich denke mit dieser Wissenslücke kann ich gut leben. ;)
Naja danke für den Denkanstoß.

Übrigens ist prototype.js das Framework und liegt am Server.

mfg
Markus

[EKKi]

Mahlzeit Markus42,

Übrigens ist prototype.js das Framework und liegt am Server.

Das ist aber eher ungünstig ... ich würd's vielleicht mal *auf* den Server packen.

MfG,
EKKi

PS: SCNR

[Kai345]

[latex]Mae  govannen![/latex]

Übrigens ist prototype.js das Framework und liegt am Server.
Das ist aber eher ungünstig ... ich würd's vielleicht mal *auf* den Server packen.

prototype.js packt man ausschließlich in die nächstgelegene Rundablage.

PS: SCNR

ebenso

Cü,

Kai

[EKKi]

Mahlzeit Kai345,

Das ist aber eher ungünstig ... ich würd's vielleicht mal *auf* den Server packen.

prototype.js packt man ausschließlich in die nächstgelegene Rundablage.

Wieso? Gibt's dafür auch objektive Gründe? Ist eins der anderen verbreiteten JS-Frameworks besser?

MfG,
EKKi

[Kai345]

[latex]Mae  govannen![/latex]

Mahlzeit Kai345,

Das ist aber eher ungünstig ... ich würd's vielleicht mal *auf* den Server packen.

prototype.js packt man ausschließlich in die nächstgelegene Rundablage.

Wieso? Gibt's dafür auch objektive Gründe? Ist eins der anderen verbreiteten JS-Frameworks besser?

Ein immer wieder heiß diskutiertes Thema.

Prototype.js baut komplett Browser-Sniffing auf:

  Browser: {  
    IE:     !!(window.attachEvent &&  
      navigator.userAgent.indexOf('Opera') === -1),  
    Opera:  navigator.userAgent.indexOf('Opera') > -1,  
    WebKit: navigator.userAgent.indexOf('AppleWebKit/') > -1,  
    Gecko:  navigator.userAgent.indexOf('Gecko') > -1 &&  
      navigator.userAgent.indexOf('KHTML') === -1,  
    MobileSafari: !!navigator.userAgent.match(/Apple.*Mobile.*Safari/)  
  }, 

das heißt, wenn _das_ schiefgeht, funktioniert ggf. gar nichts mehr richtig, weil die Verzweigungen immer wieder auf diesem ermittelten Wert basieren. Und daß Sniffing die schlechtest-mögliche Ermittlungsgstategie eine(s|r) Browser(s|version) ist, sollte bekannt sein. Sogar JQuery hat es in den neuesten Versioenen nach langem Kampf inzwischen abgeschafft.

• Prototype.js erweitert im großen Stil die Basis-Objekte (die Meinungen, ob das schlecht ist, sind allerdings sehr geteilt; Crockford z.B. befürwortet es, solange es in einem sehr kontrollierten Rahmen bleibt).
   Texte zu den Problemen, die manche damit sehen: 1 en 2 en

Dieser Thread (en) (leider nur über den minderwertigen Newsreader-Ersatz Google Groups) befasst sich damit, es gibt viele weitere. Schon die erste Antwort von David Mark fasst die Problem kurz zusammen.

Cü,

Kai

[molily]

das heißt, wenn _das_ schiefgeht, funktioniert ggf. gar nichts mehr richtig, weil die Verzweigungen immer wieder auf diesem ermittelten Wert basieren. Und daß Sniffing die schlechtest-mögliche Ermittlungsgstategie eine(s|r) Browser(s|version) ist, sollte bekannt sein. Sogar JQuery hat es in den neuesten Versioenen nach langem Kampf inzwischen abgeschafft.

Was heißt denn »selbst jQuery« - soweit ich weiß, ist jQuery die erste Bibliothek, die ihre Strategie diesbezüglich grundsätzlich ändert. Dadurch ändert sich intern erstmal nicht alles zum Positiven. Das Browsersniffing wurde keineswegs willkürlich verwendet, sondern dann, wenn die üblichen Objektabfragen nicht zum Ziel geführt haben. Jetzt müssen am Anfang erstmal einige Feature-Erkennungen laufen, damit die Bibliothek auf diesen aufbauen kann. Browserbugs und -eigenheiten durch Tests zu erkennen, ist dann wieder eine Wissenschaft für sich und kann genauso fehlerträchtig sein.

Insofern mag sich der Verzicht auf Browsererkennung über navigator irgendwie zukunftssicherer anfühlen, aber ob sich das an den schwierigen Stellen in der Praxis bewährt, halte ich immer noch für unentschieden.

• Prototype.js erweitert im großen Stil die Basis-Objekte (die Meinungen, ob das schlecht ist, sind allerdings sehr geteilt; Crockford z.B. befürwortet es, solange es in einem sehr kontrollierten Rahmen bleibt).

Wirklich elegant kommt man nicht heraus - entweder man baut sich seine eigene Objekthierarchie mit 29 Namespaces, baut abgeleitete, erweiterte Objekttypen (MyString, MyNumber, MyArray) oder erweitert schlicht die bestehenden Objekttypen prototypisch, wie es das Grundkonzept von JavaScript nahelegt. Um alle Probleme dabei zu umschiffen, fehlen JavaScript gewisse OO-Fähigkeiten.

Texte zu den Problemen, die manche damit sehen: 1 en

»Prototype makes associative arrays unreliable when it comes to using the for(x in array) loop.«

Ja ach. Da hat gerade jemand die Prototype Chain entdeckt. It's a bug, not a feature! Es lassen sich nunmal keine nicht-enumerable member in ECMAScript setzen. Das ist vielmehr eine Schwäche von ECMAScript als ein Argument gegen die Verwendung des Prototype-Objektes. Bei for-in ist IMMER hasOwnProperty zu nutzen. Erweiterungen wie Function.prototype.bind sind ultrapraktisch und genial!

2 en

»When a method is added to a JavaScript implementation, the then native method and the previously user defined method may not be exactly the same which breaks programs. Real cases of this problem have occurred. We need to learn from history and improve our practices accordingly.«

Sprachen und Interpreter entwickeln sich halt weiter (derzeit vor allem proprietär) und das, was man früher selbst einbauen musste, bringen sie in neueren Versionen mit sich. Als ob das Problem nur JavaScript beträfe.
Wenn ein Script also zu einer neuen Sprach- oder Interpreterversion kompatibel sein soll, dann ist eine Migration angesagt. Das gilt natürlich verschärft für Erweiterung der Kernobjekt-Prototypen, aber das würde ich nur als Teil eines größeren Problems sehen. if (document.all) else if (document.layers) war seinerzeit angebracht, aber neue Techniken und Interpreter kamen, sodass diese Scripte überarbeitet werden mussten. Das sind m.E. einfach die Grenzen von Vorwärtskompatibilität. Um die muss man wissen, wenn man versucht, durch prototypische Erweiterung Lücken zu schließen. Aber das war es auch. Die Welt wird nicht untergehen.

Dieser Thread (en)

... zeigt mit seiner Diskussionskultur lediglich deutlich, warum man dem Usenet und dessen Gestalten vor allem den Rücken zukehren sollte.
Also ich habe bei der Lektüre überhaupt nichts gelernt. Kannst du das nochmal für mich zusammenfassen? Vielleicht habe ich einfach eine zu unterschiedliche Perspektive, als dass ich solchen Spiegelfechtereien etwas abgewinnen könnte.

Mathias

[Struppi]

Dieser Thread (en)

... zeigt mit seiner Diskussionskultur lediglich deutlich, warum man dem Usenet und dessen Gestalten vor allem den Rücken zukehren sollte.
Also ich habe bei der Lektüre überhaupt nichts gelernt. Kannst du das nochmal für mich zusammenfassen? Vielleicht habe ich einfach eine zu unterschiedliche Perspektive, als dass ich solchen Spiegelfechtereien etwas abgewinnen könnte.

Ich bin zwar auch kein großer Freund solcher Frameworks, aber halte diese emotionale, ja fast haßerfüllte, Argumentation gegen diese für Unsinnig, Kontraproduktiv und, wie du schon sagst, es gibt dabei nichts zu lernen. es werden hirngespinnste aufgebaut, warum ein (oft nicht existenter Browser) dieses oder jenes in einem FW nicht mitmacht, aber es wird dabei ignoriert welcher Aufwand z.T. betrieben werden muss, um all die Funktionalitäten Browserübergreifend und schnell genug umzusetzen.

Schön zusammengefaßt hat das timothytoe in diesem Thread (mir gefällt auch seine Ausdrucksweise: "Until a clj Nazi codes a "correct" library with the capabilities of jQuery or Prototype or YUI, those libraries will be continue to be used to make websites." oder "I agree that browser-sniffing is about as appealing as anus-sniffing,...")

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

Ich bin zwar auch kein großer Freund solcher Frameworks, aber halte diese emotionale, ja fast haßerfüllte, Argumentation gegen diese für Unsinnig, Kontraproduktiv und, wie du schon sagst, es gibt dabei nichts zu lernen. es werden hirngespinnste aufgebaut, warum ein (oft nicht existenter Browser) dieses oder jenes in einem FW nicht mitmacht, aber es wird dabei ignoriert welcher Aufwand z.T. betrieben werden muss, um all die Funktionalitäten Browserübergreifend und schnell genug umzusetzen.

Tja, in clj laufen ein paar lautstarke Gestalten herum, die sich für den Nabel der Welt halten und alles wegbeißen, was in ihren Augen unwürdig ist. Ich mit meinen ~15 Jahren Usenet-Erfahrung habe mich halt schon dran gewöhnt und springe beim ersten Auftreten derartiger Verhaltensweisen in den Postings eben zum nächsten Beitrag oder in extremen Fällen wird halt gefiltert. Irgendwie muß ich die Funktionalität meines Newsreaders ja schließlich nutzen ;) Außerdem sind viel Gruppen lesbar haben ein intaktes Sozialklima.

Schön zusammengefaßt hat das timothytoe in diesem Thread (mir gefällt auch seine Ausdrucksweise: "Until a clj Nazi codes a "correct" library with the capabilities of jQuery or Prototype or YUI [...]

Können wir wohl lange drauf warten.

oder "I agree that browser-sniffing is about as appealing as anus-sniffing,..."

Na ja, diesen Absatz halte ich für weniger gelungen, weil es die sniffing und die Nachteile relativiert.

Es ist einfach schlechter Programmier-Stil, zu sagen »Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.«

Warum nicht einfach dafür sorgen, daß alle was davon haben?

Cü,

Kai

[Struppi]

oder "I agree that browser-sniffing is about as appealing as anus-sniffing,..."

Na ja, diesen Absatz halte ich für weniger gelungen, weil es die sniffing und die Nachteile relativiert.

Es ist einfach schlechter Programmier-Stil, zu sagen »Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.«

Ich kann mich erinnern, dass ich auch gerne diese Zeilen in jquery als Beispiel für deren Unbrauchbarkeit benutzt habe, aber diese sind, soweit ich weiß, nicht mehr vorhanden - grad nachgeschaut:

// Use of jQuery.browser is deprecated.
// It's included for backwards compatibility and plugins,
// although they should work to migrate away.

var userAgent = navigator.userAgent.toLowerCase();

Das Objekt wird ansonsten im Code nicht mehr benutzt. Diesere Kritikpunkt hat sich also erledigt.

Warum nicht einfach dafür sorgen, daß alle was davon haben?

Weil alle nicht geht. Natürlich kann man versuchen möglichst viel Browser und möglichst viele individuelle Nuancen der Browserkonfiguration abzufragen und offensichtlich arbeiten die Entwickler auch daran. Aber - du meine Güte - wir sprechen von JS Code auf Internetseiten, wenn etwas nicht funktioniert, wird der User entweder versuchen seine Einstellungen anzupassen (Wer den UA String ändern kann, sollte dazu in der Lage sein) oder er besucht eine andere Seite. Alles kein Weltuntergang.

Ausserdem, hat jemand sich mal die Mühe gemacht zu schauen, wofür dieses Browsersniffing verwendet wurde? Wurde dadurch tatsächlich der Weltuntergang provziert?

Aber wie du schon sagst (und schön zusammengefaßt hast :-)) ist einfach die Art und Weise der Kritik teilweise unerträglich und die Leute, die solche Frameworks benutzen wird das herzlich wenig interessieren, sie funktionieren in den Browsern, die in Agenturen getestet werden, die Effekte und die Geschwindigkeit sind z.T. beeindruckend.

Und zu guter letzt muss man natürlich auch sehen, dass gerade diese Frameworks die Verbreitung und Akzeptanz von JS enorm gefördert haben

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

Weil alle nicht geht. Natürlich kann man versuchen möglichst viel Browser und möglichst viele individuelle Nuancen der Browserkonfiguration abzufragen und offensichtlich arbeiten die Entwickler auch daran. Aber - du meine Güte - wir sprechen von JS Code auf Internetseiten, wenn etwas nicht funktioniert, wird der User entweder versuchen seine Einstellungen anzupassen (Wer den UA String ändern kann, sollte dazu in der Lage sein) oder er besucht eine andere Seite. Alles kein Weltuntergang.

Es gibt durchaus Seiten, zu denen leider keine Alternative besteht (z.B. Alleinvertrieb). Oder man hat sich schon durch -zig Seiten gehangelt, Formulare ausgefüllt etc. und dann geht nix mehr, weil durch einen JS-Fehler der Submit nicht mehr funktioniert. Das ist einfach nur schlampig.

Natürlich kann man nicht wirklich für alle möglichen Browser und Situationen programmieren, aber man sollte immer möglichst viel berücksichtigen und - ganz wichtig - dafür sorgen, daß z.B. wenn ein Teil des JS nicht kompatibel ist, daß dieser Teil sauber verlassen wird und ggf. der Rest des Codes noch ausgeführt werden kann. Und das vermisse ich leider immer häufiger. Das hat jetzt nicht speziell mit irgendwelchen JS-Bibliotheken zu tun, gerade dort wird oft versucht, möglichst viele Situationen abzufangen, sondern die verbreitete Einstellung "Ich teste das mit dem neuesten IE und dem neuesten FF und wer das nicht hat, hat eben Pech gehabt". Halte ich einfach für nicht akzeptabel.

Und zu guter letzt muss man natürlich auch sehen, dass gerade diese Frameworks die Verbreitung und Akzeptanz von JS enorm gefördert haben

Zeifellos. Leider hat es meiner Meinung nach aber auch zu viel zu viel Unsinn auf Webseiten geführt, es nervt einfach, wenn ständig irgendwas auf- oder zugleitet, aufpoppt oder man ohne JS nur eine leere Seite zu sehen bekommt, weil "man" ja Web 2.0 (kotz) Seiten schreibt und daher sämtliche Inhalte per Ajax einbindet. Leider werden sehr viele Seiten gerade wegen der Verbreitung und einfachen Verwendbarkeit der JS-Bibliotheken unbenutzbar.

Cü,

Kai

[Struppi]

Weil alle nicht geht. Natürlich kann man versuchen möglichst viel Browser und möglichst viele individuelle Nuancen der Browserkonfiguration abzufragen und offensichtlich arbeiten die Entwickler auch daran. Aber - du meine Güte - wir sprechen von JS Code auf Internetseiten, wenn etwas nicht funktioniert, wird der User entweder versuchen seine Einstellungen anzupassen (Wer den UA String ändern kann, sollte dazu in der Lage sein) oder er besucht eine andere Seite. Alles kein Weltuntergang.

Es gibt durchaus Seiten, zu denen leider keine Alternative besteht (z.B. Alleinvertrieb). Oder man hat sich schon durch -zig Seiten gehangelt, Formulare ausgefüllt etc. und dann geht nix mehr, weil durch einen JS-Fehler der Submit nicht mehr funktioniert. Das ist einfach nur schlampig.

gegen schlampige Programmierer helfen aber auch keine clj oder dclj konforme Frameworks.

... sondern die verbreitete Einstellung "Ich teste das mit dem neuesten IE und dem neuesten FF und wer das nicht hat, hat eben Pech gehabt". Halte ich einfach für nicht akzeptabel.

Nervt mich auch, aber es geht ja um die Framworks, die in aller Regel auch funktionieren.

Und zu guter letzt muss man natürlich auch sehen, dass gerade diese Frameworks die Verbreitung und Akzeptanz von JS enorm gefördert haben

Zeifellos. Leider hat es meiner Meinung nach aber auch zu viel zu viel Unsinn auf Webseiten geführt, es nervt einfach, wenn ständig irgendwas auf- oder zugleitet, aufpoppt oder man ohne JS nur eine leere Seite zu sehen bekommt, weil "man" ja Web 2.0 (kotz) Seiten schreibt und daher sämtliche Inhalte per Ajax einbindet. Leider werden sehr viele Seiten gerade wegen der Verbreitung und einfachen Verwendbarkeit der JS-Bibliotheken unbenutzbar.

Mir geht es da ähnlich wie dir. Aber leider scheint der Wunsch nach zappelnden Seiten in manchen Agenturen sehr groß zu sein. Letztlich hat man hier die Wahl zwischen JS oder Flash und da ziehe ich, als Besucher, in jedem Fall die JS Variante vor - aber nur wenn es keine Alternative gibt.

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

das heißt, wenn _das_ schiefgeht, funktioniert ggf. gar nichts mehr richtig, weil die Verzweigungen immer wieder auf diesem ermittelten Wert basieren. Und daß Sniffing die schlechtest-mögliche Ermittlungsgstategie eine(s|r) Browser(s|version) ist, sollte bekannt sein. Sogar JQuery hat es in den neuesten Versioenen nach langem Kampf inzwischen abgeschafft.

Was heißt denn »selbst jQuery« - soweit ich weiß, ist jQuery die erste Bibliothek, die ihre Strategie diesbezüglich grundsätzlich ändert.

… nachdem J.Resig lange Zeit heftigen Widerstand dagegen geleistet hatte, darauf zu verzichten, ja. Deshalb diese Formulierung.

Dadurch ändert sich intern erstmal nicht alles zum Positiven. Das Browsersniffing wurde keineswegs willkürlich verwendet, sondern dann, wenn die üblichen Objektabfragen nicht zum Ziel geführt haben. Jetzt müssen am Anfang erstmal einige Feature-Erkennungen laufen, damit die Bibliothek auf diesen aufbauen kann. Browserbugs und -eigenheiten durch Tests zu erkennen, ist dann wieder eine Wissenschaft für sich und kann genauso fehlerträchtig sein.

Ich halte es ohnehin für unmöglich, diesbezüglich hundertprozentige Sicherheit zu erreichen, dazu gibt es zu viele Engines in zu vielen Versionen, aber man sollte sich zum Ziel setzen, so nahe wie möglich heranzukommen. Mag sein, daß jQuery bis vor kurzem (d.h bevor das Sniffing abgeschafft wurde) nur noch gezielt eingesetzt worden ist, aber ich meine, daß es nicht immer so war. jQuery bewegt sich jedenfalls - im Gegensatz zu prototype.js, mootools usw. langsam in die richtige Richtung.

Insofern mag sich der Verzicht auf Browsererkennung über navigator irgendwie zukunftssicherer anfühlen, aber ob sich das an den schwierigen Stellen in der Praxis bewährt, halte ich immer noch für unentschieden.

Es verringert die Fehldeutbarkeit von Browsern und damit Fehleranfälligkeit. Auf manchen Seiten unfähiger Autoren kommt man leider nur weiter, wenn man "sich" als FF oder IE ausgibt. Wenn man dann per Sniffing als falscher Browser erkannt wird, kommt man unter Umständen trotzdem nicht weiter, wenn die falschen Eigenschaften/Methoden herangezogen werden.

• Prototype.js erweitert im großen Stil die Basis-Objekte (die Meinungen, ob das schlecht ist, sind allerdings sehr geteilt; Crockford z.B. befürwortet es, solange es in einem sehr kontrollierten Rahmen bleibt).

Wirklich elegant kommt man nicht heraus - entweder man baut sich seine eigene Objekthierarchie mit 29 Namespaces, baut abgeleitete, erweiterte Objekttypen (MyString, MyNumber, MyArray) oder erweitert schlicht die bestehenden Objekttypen prototypisch, wie es das Grundkonzept von JavaScript nahelegt. Um alle Probleme dabei zu umschiffen, fehlen JavaScript gewisse OO-Fähigkeiten.

Wie ich in der Klammer schon andeutete, gibt es halt verschiedene Meinungen. Ich halte mich da eher raus (und erweitere eher moderat).

Dieser Thread (en)

... zeigt mit seiner Diskussionskultur lediglich deutlich, warum man dem Usenet und dessen Gestalten vor allem den Rücken zukehren sollte.
Also ich habe bei der Lektüre überhaupt nichts gelernt. Kannst du das nochmal für mich zusammenfassen?

Gerne, sogar übersetzt:

1. Idiot!
2. Selber Idiot
3. Du hast keine Ahnung von Javascript
4. Vollidiot
5. Leg dir nen Namen zu
6. Ihr seid alle doof!
7. Lerne quoten!
8. Komm wieder, wenn du Javascript gelernt hast
#Zufallszahl(0,4)
#Wenn 1 oder 3 gehe zu 1.
#Wenn 2 oder 4 gehe zu 4.
9. *plonk*

(Der Autor hat sich gewisse künstlerische Freiheiten bezüglich Übersetzung und Kernaussagen herausgenommen sowie die Threadlogik in Pseudocode eingefügt)

Cü,

Kai

[molily]

2 en

Noch lustiger und m.M.n. einfach abwegig ist der Vorschlag, dass man jede seiner Methoden selbst an den Prototypen mit Namespace-Präfixen versehen sollte, am besten hierarchisch als umgekehrter Domainname.

Es ist nicht toll, dass Bibliotheken, die auf Wiederverwendbarkeit zielen, den globalen Namensraum und die Kernobjekte »verpesten«. Dahinter steckt aber eher das »totalitäre« Konzept von Prototype und Co. Konflikte sind vorprogrammiert, sodass eigentlich alle weiteren Scripte »Plugins« des verwendeten Frameworks sein müssen, deren Schnittstellen automatisch erkennen müssen (also Framework-übergreifend mit deren Hilfe arbeiten) oder extrem vorsichtig arbeiten und auf Koexistenz setzen müssen.

Eine wirklich elegante Lösung kenne ich nicht. Ultralange Namespace-Ketten wie YAHOO.util.Module.methode und dergleichen gehen mir gegen den Strich und sind genau das, was ich mit einer Bibliothek mit einem vernünftigen Konzept zu vermeiden suche. Gleichzeitig halte ich eine komplette Kapselung und die Erfindung eines eigenen Universums wie in jQuery für »nicht JavaScript-gerecht« - wozu habe ich denn das DOM mit seinen schönen Interfaces und ECMAScript mit erweiterbaren Kernobjekten.

Die Anforderungen, die Michaux u.a. an Bibliotheken herantragen (bloß keine globalen Objekte erweitern!), halte ich für viel zu hoch. Absurd wird es, wenn er sogar fordert, selbst alle Bezeichner im HTML mit Präfixen zu versehen. Auf so ein fundamentales Dilemma, wie es Michaux ausführt, bin ich eigentlich noch nie bei der JavaScript-Programmierung gestoßen. Die Frage für mich ist, wieviel Kompatibilität mit anderem, fremden Code nötig ist, um Kollisionen zu vermeiden, und wie zukunftsfähig JavaScript-Code überhaupt sein kann und im Einzelfall muss.

Mein Interesse ginge auch eher in die andere Richtung: Nicht das Wegkapseln sollte man mal diskutieren, sondern das Etablieren von grundlegenden Funktionen. Die Zersplitterung und der Plugin-Wust geht mir nämlich auf die Nerven. Es ist doch absurd, dass jedes Script das Rad neu erfinden muss - oder einen eigenen Abstraktionslayer über die Abstraktionslayer der fünf großen Frameworks legen muss, um von ihnen unabhängig zu sein, aber mit ihnen zusammenarbeiten zu können.

Daher finde ich den Ansatz von base2 schon sehr gut, einfach die Standard-APIs browserübergreifend zu implementieren. Denn mit den neuesten Standards kann man schon vergleichsweise effizient, übersichtlich und größtenteils schmerzfrei programmieren (Verbesserungen gehen natürlich immer). Insofern freue ich mich auch insgeheim, dass Browserhersteller proprietäre Alleingänge machen und einfach Tatsachen schaffen, wie in Mozilla JS 1.6 - 1.8 geschehen. Da ist das Geschrei immer sehr groß, aber es werden endlich, wenn auch auf unschönem Wege, Konventionen wie Array.prototype.each und Co. etabliert.

Mathias

[Christoph]

Moin.

Insofern freue ich mich auch insgeheim, dass Browserhersteller proprietäre Alleingänge machen und einfach Tatsachen schaffen, wie in Mozilla JS 1.6 - 1.8 geschehen.

Wobei man dazu sagen muss, dass Mozilla ja die Hüter des 'offiziellen' JavaScript sind: Sie besitzen eine Lizenz für den Namen (der ein Warenzeichen von Sun ist) und mit Brendan Eich ist dort der Erfinder der Sprache ein 'Chief Technology Officer'.

Der nächste ECMA-Standard 3.1 wird viele der Mozilla-Erweiterungen absegnen...

Christoph

[Christoph]

Moin.

Ist eins der anderen verbreiteten JS-Frameworks besser?

Ob es 'besser' ist sei mal dahingestellt, aber was die Popularität betrifft, schein jQuery groß im Kommen. Unter anderem integriert Microsoft jQuery-Unterstützung in Visual Studio.

Andere populäres Frameworks sind MooTools und dojo.

Dann gibt es da noch Dean Edward's base2, das Standard-APIs und Mozilla-Erweiterungen browserübergreifend zur Verfügung stellt.

Kein Framework, aber als freistehende Selector-Engine kann man noch NWMatcher von Diego Perini empfehlen: Bei meinem letzen Test war sie schneller als alles andere, ist aber auch schon etwas her.

Mir persönlich sind solche Frameworks zu mächtig, ich koche mir lieber mein eigenes Süppchen. Aber da ich damit nicht meine Brötchen verdienen muss, stehe ich auch nicht unter dem Zwang, möglichst effizient arbeiten zu müssen.

Christoph

[Kai345]

[latex]Mae  govannen![/latex]

Ist eins der anderen verbreiteten JS-Frameworks besser?
Ob es 'besser' ist sei mal dahingestellt, aber was die Popularität betrifft, schein jQuery groß im Kommen. Unter anderem integriert Microsoft jQuery-Unterstützung in Visual Studio.

</sachlich>Wenn man die Qualität von IE betrachtet, eine passende Kombination ;)<sachlich>

Andere populäres Frameworks sind MooTools und dojo.

Moo (Immer noch comp.lang.javascript, diesmal etwas anders aufbereitet)

Mir persönlich sind solche Frameworks zu mächtig, ich koche mir lieber mein eigenes Süppchen. Aber da ich damit nicht meine Brötchen verdienen muss, stehe ich auch nicht unter dem Zwang, möglichst effizient arbeiten zu müssen.

Mich stört an diesen „Frameworks“ (unsinniger Name übrigens) - ganz abgesehen von der Code-Qualität -

a) die schiere Größe, die man den Nutzern zumutet (das sind tw. sogar minified 70-130kB und mehr, und zwar für _jede_ Site)

b) der Versuch, alle "Probleme" lösen zu wollen und damit überdimensionierte JS-Libraries zu kreieren, von denen meist nur max. 5-10% wirklich benötigt werden

c) das, was David Mark im Prototype-Thread mit »It is horribly inefficient.  Even the lowest level code is tangled up
in syntactic sugar«. bezeichnet, nur um einen gewissen pseudo-elegant wirkenden Schreibstil hinzubekommen.

Wen man schon Fremdcode nutzt (und wer tut das nicht?) dann wenigstens modular aufgebaute Libraries, wie z.B. Fork (das ich immer noch nicht getestet habe) oder ... (Name vergessen, ich versuche morgen mal, es zu finden)

Cü,

Kai

[molily]

Mich stört an diesen „Frameworks“ (unsinniger Name übrigens) - ganz abgesehen von der Code-Qualität -

a) die schiere Größe, die man den Nutzern zumutet (das sind tw. sogar minified 70-130kB und mehr, und zwar für _jede_ Site)

Das ist einfach eine Rechnung, die man machen muss - früher hat man genauso viel in Spaghetticode geschrieben. Wenn man Bibliotheken richtig einsetzt, wird dafür der eigene Code sehr klein. Und bestenfalls nutzt man externe CDNs, sodass Standardbibliotheken auch nicht auf jeder Site neu geladen werden müssen.

b) der Versuch, alle "Probleme" lösen zu wollen und damit überdimensionierte JS-Libraries zu kreieren, von denen meist nur max. 5-10% wirklich benötigt werden

Bibliotheken lösen nicht alle Probleme, sondern die häufigsten, die einem beim DOM Scripting begegnen. Manches braucht man häufiger, manches seltener. Im Allgemeinen würde ich aber sagen, dass z.B. jQuery die Standardaufgaben der heutigen üblichen JavaScript-Anwendung abdeckt.

Sicherlich könnte man das weiter auf das Wichtigste eindampfen, aber eine Bibliothek ist eben eine Software, die verschiedenen Anforderungen genügen soll. Alleine dass eine Software mehr Features hat als ich gerade (!) benötige, ist kein Argument gegen sie.

c) das, was David Mark im Prototype-Thread mit »It is horribly inefficient.  Even the lowest level code is tangled up
in syntactic sugar«. bezeichnet, nur um einen gewissen pseudo-elegant wirkenden Schreibstil hinzubekommen.

Was heißt Effizienz?
JavaScript-Bibliotheken legen viel Wert auf Performance und Standardaktionen sind sehr stark auf Performance optimiert. Überhaupt wissen wir das, was wir heute über JavaScript-Performance wissen, vor allem aus der Entwicklung von Bibliotheken. Das bekommt man zu Fuß nur hin, wenn man wirklich sehr, sehr viel Detail-Know-How hat. Das ist weder sinnvoll noch möglich für normale JavaScript-Entwickler.

Der Schreibstil ist nicht pseudo-elegant, sondern abstrakt. Solchen lesbaren Code sollte man in jedem Fall programmieren - ob nun mit eigenen Mitteln (erfordert wiederum viel Erfahrung) oder fremder Hilfe.

Wen man schon Fremdcode nutzt (und wer tut das nicht?) dann wenigstens modular aufgebaute Libraries, wie z.B. Fork (das ich immer noch nicht getestet habe) oder ... (Name vergessen, ich versuche morgen mal, es zu finden)

Der Spaß z.B. bei jQuery ist doch das einheitliche Konzept von Knotenlisten und Chaining, bei Prototype und Mootools die »erweiterten« Elementobjekte.

FORK:

var finds = FORK.Dom.getElementsByClass('orange', {
  root: document.getElementById('div'),
  tag: 'li'
});
for (var i = 0; i < finds.length; i++) {
   FORK.Style.setStyle(finds[i], 'width', '123px');
}

Wenn ich mir selbst ein Helferscript schreibe, dann doch nicht eins, wo ich immer noch Spaghetti-Code wie den obigen schreiben muss. Gut, das ist halt sehr stark von YUI beeinflusst, wobei es in YUI zumindest so ginge:

YAHOO.util.Dom.setStyle(YAHOO.util.Selector.query("div li.orange"), 'width', '123px');

Hingegen:

Mootools: $$('div li.orange').setStyle('width', '123px')
jQuery: jQuery('div li.orange').css('width', '123px')

Das API, die ich mir auch selbst bauen würde. Der Clou von Frameworks (für mich zumindest) ist, dass sie prototypische Erweiterung nutzen (Prototype, Mootools) oder zumindest ein Wrapper-Objekttyp bieten, wie die Knotenlisten bei jQuery, die wiederum alle Element-Methoden besitzen. Den Umweg über knotenliste.each(function () { ... }) oder invoke() bei Prototype finde ich nicht ganz so komfortabel, aber immerhin nicht schlecht.

Mathias

[molily]

YAHOO.util.Dom.setStyle(YAHOO.util.Selector.query("div li.orange"), 'width', '123px');

Das kommende YUI 3 ändert das in:

YUI().use('node', function (Y) {
 Y.all('div li.orange').setStyle('width', '123px');
});

Eigentlich ziemlich cool, kannte ich noch gar nicht. Sehr interessant, dass die sich vom Konzept der Namespace-Schlange verabschiedet haben (bei YUI 2 hat man ohnehin ständig mit lokalen Shortcuts wie z.B. YD für YAHOO.util.Dom gearbeitet).

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Ich habe heute einige schwere Probleme und daher keine Konzentration, um auf alles einzugehen oder jede Formulierung hundertprozentig abzusichern (kann auch sein, daß ich viel unsinn schreibe, ich kanns heute nicht besser), daher nur ein kurzer Abschnitt:

Der Spaß z.B. bei jQuery ist doch das einheitliche Konzept von Knotenlisten und Chaining, bei Prototype und Mootools die »erweiterten« Elementobjekte.

Ich halte gerade chaining (nicht nur im Kontext JS-"Framework") in vielen (nicht allen) Fällen für sehr schlechten Programmier-Stil. Es wird einfach davon ausgegangen, daß die Funktion schon das zurückgeben wird, was man erwartet. Und wenn dies nicht so sein sollte, hat man ein Problem, und ein JS-Anfänger steht dann da und läßt irgendwelche Foren das Problem für sich lösen.

Ich würde noch nicht einmal eine einfache Form, z.B. document.getElementById("bla").style.width = "200px"; schreiben, sondern immer den Rückgabewert von document.getElementById abfragen, möglichst auch noch den erwarteten (node|Objekt)Typ.

Solche Frameworks vermitteln den Eindruck, man müsse nur ein paar Zeilen Code schreiben (oder per c&p einfügen) und sich ansonsten nicht um Javascript-Programmierung kümmern. Und wenn irgendwas nicht so klappt, wie man es sich vorstellt, fängt man an, alles aufzudröseln.

YAHOO.util.Dom.setStyle(YAHOO.util.Selector.query("div li.orange"), 'width', '123px');

Hingegen:

Mootools: $$('div li.orange').setStyle('width', '123px')
jQuery: jQuery('div li.orange').css('width', '123px')

Und genau das halte ich für Augenwischerei und den angekreidetetn "syntatic sugar". Was habe ich davon, wenn ich nur eine Zeile in meinemCode habe, aber dafür im Hintergrund Unmengen von Funktionen durchlaufen werden müssen? Ich finde es nicht mehr, aber jemand hat in einem _konkreten Beispiel_ nachgewiesen, daß um einen solchen Einzeiler für eine relativ simple Aktion zu erreichen, im Hintergrund innerhalb des Frameworks 27 oder 28 Funktionsaufrufe getätigt wurden. Genau das Gleiche hat er mit 3 Funktionen hinbekommen.

Cü,

Kai

[Kai345]

[latex]Mae  govannen![/latex]

Ich habe heute einige schwere Probleme und daher keine Konzentration, um auf alles einzugehen oder jede Formulierung hundertprozentig abzusichern (kann auch sein, daß ich viel unsinn schreibe, ich kanns heute nicht besser), daher nur ein kurzer Abschnitt:

[allerlei]

Ähm, vergiß es. Da sind schon wieder so viele Dinge mit unterschiedlichen Kontext in einem Satz verschwurbelt, daß man das fast mißverstehne muß. Ich geh wieder ins Bett.

Cü,

Kai

[molily]

Was habe ich davon, wenn ich nur eine Zeile in meinemCode habe, aber dafür im Hintergrund Unmengen von Funktionen durchlaufen werden müssen?

Ganz viel. Ich kann sehr schnell zu Ergebnissen kommen und in meinem Quellcode kümmere ich mich um die reine Programmlogik, anstatt mich immer wieder mit dem Durchlaufen von Knotenlisten aufzuhalten.

Natürlich habe ich einen Overhead dadurch, aber dieses Tauschgeschäft habe ich bei Vereinfachung, Abstraktion und Frameworks immer. Problematisch wird das nur, wenn darunter wirklich die Performance leidet. Das tut sie aber m.M.n. nur wenig. JavaScript explodiert hinsichtlich Performance. Wir leben in einer Welt, in der es die JavaScript-Interpreter mit anderen hochoptimierten Plattformen aufnehmen können, auf der dicke Anwendungen laufen. Außerdem lässt sich so ein Chaining-System auch sehr einfach umsetzen.

Ich finde es nicht mehr, aber jemand hat in einem _konkreten Beispiel_ nachgewiesen, daß um einen solchen Einzeiler für eine relativ simple Aktion zu erreichen, im Hintergrund innerhalb des Frameworks 27 oder 28 Funktionsaufrufe getätigt wurden. Genau das Gleiche hat er mit 3 Funktionen hinbekommen.

Genau das gleiche bestimmt nicht. Die Flexibilität wird eben durch Komplexität in der Bibliothek erkauft. Mag sein, aber ehrlich gesagt: Inwiefern betrifft mich das negativ? Ich habe schon oft neben der jeweils verwendeten Bibliothek programmiert, wenn ich Performance brauchte. Aber 90% aller Operationen sind 08/15 Event-Handling, Traversing, Manipulation usw. Dabei kommt es auf eine Millisekunde mehr oder weniger einfach nicht an, diese Standardsachen sind mittlerweile einfach schnell, ob mit oder ohne Bibliothek. Was dort durch viele Funktionsaufrufe verloren geht, gewinne ich dadurch, dass die tatsächlichen Operationen sehr stark optimiert sind, weil mehrere Jahre Entwicklung in der Bibliothek stecken. Da bin ich »zu Fuß» gar nicht unbedingt schneller, speichereffizienter usw.

Mathias

[Christoph]

Moin.

a) die schiere Größe, die man den Nutzern zumutet (das sind tw. sogar minified 70-130kB und mehr, und zwar für _jede_ Site)

Gzip-Kompression sei Dank ist das mit den 130kB übertrieben. Und als Workaround wird von einigen empfohlen, das Script von einer zentralen Stelle zu laden (z.B. http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js), anstatt es selbst bereitzustellen. So funktioniert dann auch das seitenübergreifende caching...

Christoph