jquery und Prototype gemeinsam nutzen?

Hallo,

Thomas 'PointedEars' Lahn wrote:

Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
ich entwickele derzeit an einem kleinen Rails-Projekt, dessen helper
Prototype benötigen.
Ich pers. bin jedoch ein überzeugter jquery-Anhänger, für den prototype
ein Krampf mit viel zu wenig Methoden ist. (*g* - ok, das klingt nach
einem Flamewar- soll es aber nicht werden).
Wird es auch nicht. Beides ist IMNSHO Müll.[1] Gern geschehen.


(Meinewetegen genauer: wesetnliche Teile der ActionView-Helper zu
verwenden)?

Ja, wenn diese clientseitig Prototype.js erfordern.

D.h. Du bist bei solchen Anwendungen dafür, den JavaScript Teil in
Plain-Old-JavaScript zu machen

Du musst jetzt ganz tapfer sein: auch Prototype.js ist nur
"Plain-Old-JavaScript", nur ist es zudem noch Müll, da deren Autor(en)
leider keine Ahnung von JavaScript geschweige denn irgend einer anderen
ECMAScript-Implementation haben. Jene(r) glaubt/glauben ja sogar,
ECMAScript-Implementationen seien keine OOPLs und man müsse ihnen deshalb
eine fehlgeschlagene Simulation klassenbasierter Vererbung aufpfropfen.
Von der bekannt fehlerträchtigen Modifikation der Prototyp-Objekte von
eingebauten Objekten ganz zu schweigen.


http://www.pseliger.de/translations/...avaScript.html

und das XMLHttpRequest-Objekt direkt anzusteuern?

Was meinst Du damit? Die Benutzung einer Implementation von Microsofts
IXMLHTTPRequest-Interface ist für diesen Ansatz *immer* nötig. Ein
Wrapper-Objekt (i.d.F. der von Prototype.js) bietet lediglich eine weitere
Abstraktionsebene. Was, wie man insbesondere an Prototype.js sieht, nicht
immer von Vorteil ist.

Es geht mir nicht darum, das Wesen von JavaScript zu leugnen oder zu
verstehen, sondern lediglich darum, in einer akzeptablen Entwicklungszeit
und einem akzeptablen Codeumfang die von meinem Chef geforderte Leistung zu
erbringen. Die Aussage: Die Prototype-/jquery Architektur ist Schrott ist
ebensowenig hilfreich wie die Aussage: HTML/JavaScript als Rich-Client
Plattform ist Schrott.
Für mich ist jQuery in erster Linie eine brauchbare API, die mit wenig Code
zu brauchbaren Resultaten führt.
Dir mag $('#element').autocomplete(..) ein Verbrechen sein, für mich ist es
ein einfacher weg, eine akzeptabel benutzbare Webanwendung zu haben - und
falls Browser xy in Version z Probleme mit jquery hat, ist dies egal, da
die Webanwendung nur in einer spezifizierten Umgebung eingesetzt wird.

Keep smiling
yanosz

Jan Luehr wrote:

Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
[...] das XMLHttpRequest-Objekt direkt anzusteuern?
Was meinst Du damit? Die Benutzung einer Implementation von Microsofts
IXMLHTTPRequest-Interface ist für diesen Ansatz *immer* nötig. Ein
Wrapper-Objekt (i.d.F. der von Prototype.js) bietet lediglich eine weitere
Abstraktionsebene. Was, wie man insbesondere an Prototype.js sieht, nicht
immer von Vorteil ist.

Es geht mir nicht darum, das Wesen von JavaScript zu leugnen oder zu
verstehen

Letzteres ist genau Dein Problem und das anderer Bibliothekslemminge. Weil
Du nicht die Sprache und die mit der Sprache benutzbaren Schnittstellen
(v.a. das DOM) kennenlernen willst, sondern nur die Schnittstelle einer
Bibliothek, die hier und i.d.R. von Leuten geschrieben wurde, welche die
Sprache und vorhandenen Schnittstellen selbst nicht richtig kennengelernt
haben und folglich in falscher und *für Dich* dann nicht nur in
ineffizienter, sondern auch fehlerträchtiger Weise verwenden.

sondern lediglich darum, in einer akzeptablen Entwicklungszeit
und einem akzeptablen Codeumfang die von meinem Chef geforderte Leistung zu
erbringen. Die Aussage: Die Prototype-/jquery Architektur ist Schrott ist
ebensowenig hilfreich wie die Aussage: HTML/JavaScript als Rich-Client
Plattform ist Schrott.

Äpfel, Birnen. Etwas, das nachgewiesenermassen Müll ist[1], benutzt man
nicht, sondern überlegt sich, wie man es geeignet ersetzen kann. Das hat
rein gar nichts damit zu tun, dass man Webapplikationen mit HTML und
ECMAScript-Implementationen realisieren kann; in Ausnahmefällen sogar ohne
Fallback.

Für mich ist jQuery in erster Linie eine brauchbare API, die mit wenig Code
zu brauchbaren Resultaten führt.
Dir mag $('#element').autocomplete(..) ein Verbrechen sein,

Ich habe meinen Hauptkritikpunkt an jQuery bereits dargelegt. Jener war
nicht die die Empfehlungen in der Sprachspezifikation missachtende Syntax
der Schnittstelle.

für mich ist es ein einfacher weg, eine akzeptabel benutzbare Webanwendung
zu haben - und falls Browser xy in Version z Probleme mit jquery hat, ist
dies egal, da die Webanwendung nur in einer spezifizierten Umgebung
eingesetzt wird.

Und schon nach dem nächsten Browser-Update (lass es den Minimalfall eines
Sicherheitsupdates sein) nicht mehr funktionieren kann, obwohl man mit einer
besser geschriebenen Bibliothek dieses Risiko nicht eingegangen wäre. Das
ist Programmierung für /dev/null.


PointedEars
___________
[1] siehe u.a. <1193694168.952251.143480 (AT) 22g2000hsm (DOT) googlegroups.com>
--
Java hat in etwa soviel mit JavaScript zu tun, wie Gummi mit Gummibärchen ;-)
-- Alexander Clauss
in <1fkgjxx.pels4b1saxyvaN%aclauss (AT) hrzpub (DOT) tu-darmstadt.de>

ja hallo erstmal,..

Thomas 'PointedEars' Lahn wrote:

Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
[...] das XMLHttpRequest-Objekt direkt anzusteuern?
Was meinst Du damit? Die Benutzung einer Implementation von Microsofts
IXMLHTTPRequest-Interface ist für diesen Ansatz *immer* nötig. Ein
Wrapper-Objekt (i.d.F. der von Prototype.js) bietet lediglich eine
weitere
Abstraktionsebene. Was, wie man insbesondere an Prototype.js sieht,
nicht immer von Vorteil ist.

Es geht mir nicht darum, das Wesen von JavaScript zu leugnen oder zu
verstehen

Letzteres ist genau Dein Problem und das anderer Bibliothekslemminge.
Weil Du nicht die Sprache und die mit der Sprache benutzbaren
Schnittstellen (v.a. das DOM) kennenlernen willst, sondern nur die
Schnittstelle einer Bibliothek, die hier und i.d.R. von Leuten geschrieben
wurde, welche die Sprache und vorhandenen Schnittstellen selbst nicht
richtig kennengelernt haben und folglich in falscher und *für Dich* dann
nicht nur in ineffizienter, sondern auch fehlerträchtiger Weise verwenden.

Bislang habe ich noch keine solchen Probleme gehabt.

sondern lediglich darum, in einer akzeptablen Entwicklungszeit
und einem akzeptablen Codeumfang die von meinem Chef geforderte Leistung
zu erbringen. Die Aussage: Die Prototype-/jquery Architektur ist Schrott
ist ebensowenig hilfreich wie die Aussage: HTML/JavaScript als
Rich-Client Plattform ist Schrott.

Äpfel, Birnen. Etwas, das nachgewiesenermassen Müll ist[1], benutzt man
nicht, sondern überlegt sich, wie man es geeignet ersetzen kann. Das hat
rein gar nichts damit zu tun, dass man Webapplikationen mit HTML und
ECMAScript-Implementationen realisieren kann; in Ausnahmefällen sogar ohne
Fallback.

Doch - genau darum geht es. Die einzelnen Browser verfügen über viele -
nicht in allen Punkten kompatible Interpreter. Da erwarte ich nicht von
einer lib über diesen Schatten zu springen.

Und schon nach dem nächsten Browser-Update (lass es den Minimalfall eines
Sicherheitsupdates sein) nicht mehr funktionieren kann, obwohl man mit
einer
besser geschriebenen Bibliothek dieses Risiko nicht eingegangen wäre.
Das
ist Programmierung für /dev/null.

Jeder Security-Fix im Browser bringt dieses Risiko mit sich.
Alle Browser - insb. Mozilla (jetzt Seamonkey) - haben damit ihre Probleme.
Die Krönung davon war, dass Debian lange Zeit keine Sec-Fixes für Mozilla
liefern konnte, da genau dies, Änderungen mit sich gebracht hätte, die zur
Unbenutzbarkeit anderer Anwendungen geführt hätten.
Dieses Risiko bleibt - und dieses Risiko kann eine besser geschriebene
Bibliothek nur unwesentlich eingrenzen.
Wenn ich wirklich stabile libs will, dann kann ich gegen die aus dem
xfree86-Projekt linken - diese werden sich in absehbarer Zeit kaum ändern.


Dieses Risiko besteht - insdb. bei Webanwendungen - immer. Dies Risiko lässt
sich auch nicht durch eine wie auch immer gute Programmierung umgehen.

Praktisch gesehen, kann's also jedes security-Fix im Kernel dieses
Kartenhaus zum einstürzen bringen - aber würdest Du deshalb Deinen eigenen
Kernel verwenden, nur um in dieser Kette nicht davon abhängig zu sein?

jQuery hat für mich eine Versionsstand erreicht, wo sich nicht viele
Änderungen in der API ergeben, d.h. wo ich darauf vertraue, dass Änderungen
meine Anwendung nicht einbrechen lassen.

Was bleibt ist eine Bibliothek die mir bislang gute Dienste geleistet hat,
ein Framework (Ruby on Rails), dass eine effiziente Webentwicklung
ermöglicht und eine JavaScript-Newsgroup, die auf Prototype schimpft,
obwohl eine Abkehr aus praktischen Gründen nicht möglich ist.

fup2 /dev/null

Jan Luehr wrote:

Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
Thomas 'PointedEars' Lahn wrote:
Jan Luehr wrote:
[...] das XMLHttpRequest-Objekt direkt anzusteuern?
Was meinst Du damit? Die Benutzung einer Implementation von Microsofts
IXMLHTTPRequest-Interface ist für diesen Ansatz *immer* nötig. Ein
Wrapper-Objekt (i.d.F. der von Prototype.js) bietet lediglich eine
weitere
Abstraktionsebene. Was, wie man insbesondere an Prototype.js sieht,
nicht immer von Vorteil ist.
Es geht mir nicht darum, das Wesen von JavaScript zu leugnen oder zu
verstehen
Letzteres ist genau Dein Problem und das anderer Bibliothekslemminge.
Weil Du nicht die Sprache und die mit der Sprache benutzbaren
Schnittstellen (v.a. das DOM) kennenlernen willst, sondern nur die
Schnittstelle einer Bibliothek, die hier und i.d.R. von Leuten geschrieben
wurde, welche die Sprache und vorhandenen Schnittstellen selbst nicht
richtig kennengelernt haben und folglich in falscher und *für Dich* dann
nicht nur in ineffizienter, sondern auch fehlerträchtiger Weise verwenden.

Bislang habe ich noch keine solchen Probleme gehabt.

Du hast es nur nicht gemerkt.

sondern lediglich darum, in einer akzeptablen Entwicklungszeit
und einem akzeptablen Codeumfang die von meinem Chef geforderte Leistung
zu erbringen. Die Aussage: Die Prototype-/jquery Architektur ist Schrott
ist ebensowenig hilfreich wie die Aussage: HTML/JavaScript als
Rich-Client Plattform ist Schrott.
Äpfel, Birnen. Etwas, das nachgewiesenermassen Müll ist[1], benutzt man
nicht, sondern überlegt sich, wie man es geeignet ersetzen kann. Das hat
rein gar nichts damit zu tun, dass man Webapplikationen mit HTML und
ECMAScript-Implementationen realisieren kann; in Ausnahmefällen sogar ohne
Fallback.

Doch - genau darum geht es. Die einzelnen Browser verfügen über viele -
nicht in allen Punkten kompatible Interpreter. Da erwarte ich nicht von
einer lib über diesen Schatten zu springen.

Du weisst offensichtlich nicht, worüber Du schreibst, was aber angesichts
der jQuery-Benutzung nicht verwunderlich ist und tatsächlich meine
Argumentation einen Absatz höher genau bestätigt. "Nicht in allen Punkten
kompatible Interpreter"? OMG.

Über den Rest Deines Postings breiten wir lieber den Mantel des Schweigens.
Geh Dich *bitte* informieren, bevor Du noch mehr Unsinn veröffentlichst.


PointedEars
--
[FrontPage] Dann wechsle schnellstens zu Notpatsch.echse, dann mußt Du
alle Buchstaben selber eingeben und Dir auch bei jedem überlegen, ob der
dahingehört bzw. weggelassen werden kann.
(Georg Maaß in dcljs <b57nm8$25hka6$1 (AT) ID-3551 (DOT) news.dfncis.de>)