Kermit: testen ob "element has no properties"

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

  1. 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)
    1. 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);
        },
      ....

      1. [latex]Moin![/latex]

        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:|]
        1. hab ich schon, gleicher Fehlermeldung

          1. mit try-catch funz
            try {

            } catch(e) {

            }

            1. 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)
              1. 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.

                1. 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

                  1. 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)
                2. 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

      2. 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)
      3. 你好 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/
    2. 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:]
      1. 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)
    3. 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