![]() |
SELFHTML Forumsarchiv |
|
|
Die folgende Nachricht zum Thema stammt von: Kermit, 01. 02. 2008, 16:12
Hi,
wie kann ich im JS testen ob ei element überhaupt eine property hat?
if ( "element has no property" ?? ) {
// mach was
}
vielen Dank und Gruß
Kermit
Die folgende Nachricht zum Thema stammt von: Rouven, 01. 02. 2008, 16:18
Hello,
»» wie kann ich im JS testen ob ei element überhaupt eine property hat?
rührt dein Drang daher, eine Browserfehlermeldung NICHT zu bekommen? "has no properties" ist des Browsers Art dir zu sagen, dass das Objekt für ihn nicht existiert. Der entsprechende Vergleich dazu lautet
if (elem == null) {
// do something
}
MfG
Rouven
--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Die folgende Nachricht zum Thema stammt von: Kermit, 01. 02. 2008, 16:26
Hi,
nein, ich benutze prototype.js und auf eine bestimmte Seite schmeißt ein Fehler:
element has no properties
if ( element.offsetTop != null ) {
dein Beispiel funz also nicht.
prototype.js 1.6 line 2006
....
cumulativeOffset: function(element) {
var valueT = 0, valueL = 0;
do {
if ( element.offsetTop != null ) {
valueT += element.offsetTop || 0;
}
valueL += element.offsetLeft || 0;
element = element.offsetParent;
} while (element);
return Element._returnOffset(valueL, valueT);
},
....
Die folgende Nachricht zum Thema stammt von: Kai345, 01. 02. 2008, 16:29

»» nein, ich benutze prototype.js und auf eine bestimmte Seite schmeißt ein Fehler:
»» element has no properties
»» if ( element.offsetTop != null ) {
»» dein Beispiel funz also nicht.
Versuche es mit typeof
Cü,
Kai
--
I got sunshine in my stomach, Like I just rocked my baby to sleep.
I got sunshine in my stomach, But I can't keep me from creeping sleep,
Sleep, deep in the deep.
ie:{ fl:( br:< va:) ls:? fo:| rl:? n4:° ss:{ de:] js:| ch:? mo:| zu:|]
Die folgende Nachricht zum Thema stammt von: Kermit, 01. 02. 2008, 16:37
hab ich schon, gleicher Fehlermeldung
Die folgende Nachricht zum Thema stammt von: Kermit, 01. 02. 2008, 16:43
mit try-catch funz
try {
} catch(e) {
}
Die folgende Nachricht zum Thema stammt von: Cybaer, 01. 02. 2008, 16:59
Hi,
»» mit try-catch funz
Nein. Damit wird nur der Fehler, den Du machst versteckt. try-catch nimmt man *nur* dann, wenn es wirklich nicht anders geht (schon aufgrund seiner Nachteile). try-catch nimmt man hingegen nicht, nur weil man es einfach nicht richtig hinbekommt. Ist letztere Situation gegeben (wie hier), heißt die funzende Lösung nicht try-catch, sondern learning-understanding.
Gruß, Cybaer
--
Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)
Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)
Die folgende Nachricht zum Thema stammt von: ZBuilder, 01. 02. 2008, 17:06
»» Hi,
»»
»» »» mit try-catch funz
»»
»» Nein. Damit wird nur der Fehler, den Du machst versteckt. try-catch nimmt man *nur* dann, wenn es wirklich nicht anders geht (schon aufgrund seiner Nachteile).
Welche Nachteile hat es denn und warum sollte man es nicht nehmen?
Ich nehme es immer aus bequemlichkeit, weil man sich damit viele Abfragen ersparen kann und es im Endeffekt auf genau dasselbe hinausläuft.
Die folgende Nachricht zum Thema stammt von: Kermit, 01. 02. 2008, 17:32
weil es wahrscheinlich zu viel overhead erzeugt und somit der Script langsamer wird.
ich habe am Anfang falsch geprüft
mit element == null funz einwandfrei
Die folgende Nachricht zum Thema stammt von: Cybaer, 02. 02. 2008, 12:27
Hi,
»» weil es wahrscheinlich zu viel overhead erzeugt und somit der Script langsamer wird.
Jep.
Gruß, Cybaer
--
Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)
Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)
Die folgende Nachricht zum Thema stammt von: molily, 01. 02. 2008, 20:07
Hallo,
»» Welche Nachteile hat es denn und warum sollte man es nicht nehmen?
»» Ich nehme es immer aus bequemlichkeit, weil man sich damit viele Abfragen ersparen kann und es im Endeffekt auf genau dasselbe hinausläuft.
Super, dann kannst du ja einfach deinen ganzen Code in ein riesiges try-catch packen und brauchst gar nicht mehr nachdenken... ;)
So wird man aber nie ein komplexes und gleichzeitig kompatibles Script hinbekommen. JavaScripte leben davon, Abfragen zu machen. Im "Fehlerfall" brechen sie nicht einfach ab, sondern laufen bestenfalls weiter, versuchen Alternativen oder brechen zumindest *kontrolliert* ab, sodass der Autor den Fehler finden kann und der Anwender ein konsistentes Resultat sieht.
Das alles ist mit try-catch unmöglich oder viel schwerer möglich. try-catch ist für ganz andere Zwecke gedacht. Damit kann man sich nichts "ersparen"!
Mathias
--
SELFHTML aktuell Weblog
Die folgende Nachricht zum Thema stammt von: Rouven, 01. 02. 2008, 16:38
Hello,
»» element has no properties
»» if ( element.offsetTop != null ) {
»» dein Beispiel funz also nicht.
doch, tut es. Bitte lies genau: element has no properties - nicht offsetTop has no properties. Element hat also keine Eigenschaften auf die man zugreifen kann, aller Wahrscheinlichkeit nach weil element==null.
MfG
Rouven
--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Die folgende Nachricht zum Thema stammt von: Christian Kruse, 01. 02. 2008, 16:38
你好 Kermit,
»» element has no properties
»» if ( element.offsetTop != null ) {
»» dein Beispiel funz also nicht.
Du hast es falsch angewendet:cumulativeOffset: function(element) {
var valueT = 0, valueL = 0;
if(element == null) return;
do {
valueT += element.offsetTop || 0;
valueL += element.offsetLeft || 0;
element = element.offsetParent;
} while (element);
return Element._returnOffset(valueL, valueT);
}
再见,
克里斯蒂安
--
Bauer sucht Frau! | Ich bin ja eigentlich kein Serien-Junkie…
Wenn du gehst, gehe. Wenn du sitzt, sitze. Und vor allem: schwanke nicht!
http://wwwtech.de/
Die folgende Nachricht zum Thema stammt von: peterS., 01. 02. 2008, 17:47
hallo Rouven, gruss Kermit,
»» »» wie kann ich im JS testen ob ei element überhaupt eine property hat?
»» rührt dein Drang daher, eine Browserfehlermeldung NICHT zu bekommen?
»» "has no properties" ist des Browsers Art dir zu sagen, dass das Objekt
»» für ihn nicht existiert. Der entsprechende Vergleich dazu lautet
»»
»» if (elem == null) {
»» // do something
»» }
ein vergleichender test auf die werte der primitiven typen [undefined] und
[null] sollte niemals mit dem vergleichsoperator [==] durchgefuehrt werden:alert(null == null) // [true] - wie zu erwarten
alert(window.undefined == null); // auch [true]
alert(0 == false); // ebenfalls [true];
wenn schon unschoen, dann bitte mit dem identitaetsoperator [===]:alert(null === null) // immer noch [true]
alert(window.undefined === null); // richtigerweise [false]
alert(0 === false); // ebenfalls richtigerweise [false];
besser waere es, einigermassen venuenftige "type detection" zu betreiben:this.isUndefined = (function (obj) {
return (typeof obj == "undefined");
});
this.isNull = (function (obj) {
//return ((typeof obj == "object") && (obj === null));
return ((typeof obj == "object") && (!obj));
});
so long - peterS. - pseliger@gmx.net
--
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
ie:( fl:) br:> va:( ls:& fo:) rl:) n3;} n4:} ss:} de:µ js:} mo:? zu:]
Die folgende Nachricht zum Thema stammt von: Cybaer, 01. 02. 2008, 18:18
Hi,
»» ein vergleichender test auf die werte der primitiven typen [undefined] und
»» [null] sollte niemals mit dem vergleichsoperator [==] durchgefuehrt werden:
Als bekennender Vertreter eines abwärtskompatiblen Programmierstils (sofern möglich) stößt mir dieses "niemals" immer sauer auf!
Ich mache mir auch lieber schon bei der Programmentwicklung Gedanken, welche Werte ich bei einer Abfrage/einem Vergleich zu erwarten habe. Bei einer Abfrage eines Object erwarte ich keine 0 oder Leerstring (bei einer Object-Eigenschaft sieht das schon anders aus).
Ansonsten stimme ich deinem Posting, insbes. was die type detection angeht, zu.
Gruß, Cybaer
--
Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)
Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)
Die folgende Nachricht zum Thema stammt von: molily, 01. 02. 2008, 20:12
Hallo,
»» Der entsprechende Vergleich dazu lautet
»» if (elem == null) {
»» // do something
»» }
Da reicht eigentlich if (elem) { ... }
Ich wüsst jetzt auf die Schnelle nicht, welchen signifikanten Unterschied == null macht (außer null == null ergibt true).
Aber das ist jetzt ziemlich allgemein, meistens will man zumindest typeof != undefined oder typeof == einen bestimmten Typ, wie gesagt.
Mathias
--
SELFHTML aktuell Weblog
© 1998-2006
Impressum, Software: Classic Forum