Hi,
ich habe meine letzten Extension zum Anlass genommen etwas mehr in JavaScript zu machen.
Wenn man sich vorhandene Extensions anschaut, die JS wie prototype oder mootools nutzen, merkt man, dass es immer wieder zu Problemen kommt ("Die beiden JS vertragen sich nicht").
Wie kann man das verhindern? Woran liegt überhaupt der Fehler (eventl. gleiche Funktionsnamen?)
Grüße, Alex
Das würde mich auch sehr interessieren... Wenn das ginge, könnte ich endlich RgTABS nutzen.
jQuery z. B. verwendet im globalen Namespace die Variable jQuery. Um den Code abzukürzen wird allerdings $ als Alias für jQuery genutzt.
Also lässt sich z. B.
jQuery('#xyz').show();
abkürzen mit
$('#xyz').show();
Allerdings wird von anderen Frameworks auch $ verwendet. Deswegen „gewinnt“ quasi immer das zuletzt geladene.
jQuery bietet allerdings die Möglichkeit, mit der noConflict-Funktion $ freizugeben, so dass es prinzipiell mit anderen Frameworks zusammen funktioniert. Trotzdem kann man dann $ im Zusammenhang mit jQuery benutzen:
(function($){
$('#xyz').html('Hier ist $ == jQuery');
})(jQuery);
ok, das war ein Beispiel. Macht es also Sinn eher auf Klassen anstatt auf nur Funktionen zu setzen? Oder noch etwas anderes?
Hallo wunsch... äh einpraegsam.net
es macht mehr Sinn auf Klassen zu setzten als auf Funktionen. Ich schätze, dass sich auch JavaScript weiterentwickeln wird und auch den nächsten, sagen wir mal Hype "Aspektorientiert", mitnimmt.
LG
Cope
Gibts irgendwo eine Anleitung like "How to create fine JS"?
Hi,
schon mal nicht schlecht - ein paar Performance Tipps.
Aber ich weiß immer noch nicht nicht warum sich prototype und mootools nicht mögen, bzw. was ich bei meinem eigenen JS verbessern kann um so etwas zu vermeiden...
Vielleicht sollte ich mal in einem JS Forum posten 🙂
Hallo,
einpraegsam.net schriebAber ich weiß immer noch nicht nicht warum sich prototype und mootools nicht mögen, bzw. was ich bei meinem eigenen JS verbessern kann um so etwas zu vermeiden...
einen konkreten Lösungsvorschlag habe ich nicht, aber gerade heute hat mich genau dieses Problem beschfätigt:
Ein Beispiel:
Auf einer Seite gibt es ein (Powermail-)Formular mit Upload-Möglichkeit und JS-Validierung.
Aufgrund des Upload-Felds, welches in jedem Browser anders breit angezeigt wird, lese ich mit Mootools die aktuelle Breite aus und setzte die anderen Input-Felder wie folgt:
window.addEvent('domready', function() {
var currentWidth = $('uid4').getSize().size.x-6;
$('uid1').setStyle('width', currentWidth);
$('uid3').setStyle('width', currentWidth);
});
Sobald die Validierung aktiviert ist, wird das Prototype-Framework geladen.
In Prototype gibt es aber auch eine Funktion setStyle, die leider eine andere Syntax, als in Mootools hat. Deshalb funktioniert das setzen der Breite nun nicht mehr.
Für Prototype müsste es wie folgt aussehen:
window.addEvent('domready', function() {
var currentWidth = $('uid4').getSize().size.x-6;
$('uid1').setStyle({width: currentWidth});
$('uid13).setStyle({width: currentWidth});
});
Mootools erst nach Prototype zu laden löst zwar das Problem mit der Breite, dann werden aber die Validation-Advices nicht mehr angezeigt, weil deren setStyle nicht mit Mootools kompatibel ist.
Mein erster Lösungsversuch war es, in prototype.js die Funktion "setStyle" in "PTsetStyle" umzubenennen und dann die Aufrufe in "effects.js", "dragdrop.js" usw. auch in PTsetStyle umzubenennen.
Das hat zwar prinzipiell funktioniert, ist aber keine schöne Lösung, da beim nächsten Update wieder alles weg ist. Zudem gibt es, so wie es aussieht noch weitere Überschneidungen in den Funktionsnahmen, sodass derzeit bei dieser Seite immer mehr Probleme auftreten.
Bei manchen Extensions kann man auswählen, ob man das Mootools oder Prototype-Framework verwenden will. Dann müsstest Du aber je nach Auswahl anderen JS-Files laden, die den jeweiligen Frameworks entsprechen. Oder Du programmierst eine Schnittstelle zu den Frameworks, also zB Wrapper-Funktionen für die benötigten Optionen. Dort rufst Du dann Deine Funktionen aus, die im Hintergrund je nach Framework die gewünschten Funktionsaufrufe machen. Das stelle ich mir aber wahnsinnig aufwändig vor. Bzw. müsste man nachschauen, wie das die andren Extension-Entwickler (die mehrere Frameworks anbieten) gehandhabt haben.
Jedenfalls bedeutet es vor allem für Dich als Extension-Entwickler mehr Aufwand, für den Benutzer der Extension hat es den Vorteil, dass nicht zwei Frameworks geladen werden müssen.
Viele Grüße
Andreas