Prüfen, ob Objekt vorhanden

[Emso]

Hallo,

zu diesem Thema gibt es viele Fundstellen, allerdings widersprüchlich.

In einem Affenformular möchte ich bei Klick auf submit eine Fehlermeldung ausblenden, falls vorhanden.

angezeigte Fehlermeldung:
<p id="fehlertext" class="fehler" style="display:block">Fout: &nbsp; Login is mislukt &nbsp; </p>

bei Klick auf submit:

  if ( typeof document.getElementById('fehlertext') != "undefined" )  
  {  
    document.getElementById('fehlertext').style.display = 'none';  
  }  

Fehlermeldung der Opera:
Uncaught exception: TypeError: Cannot convert 'document.getElementById('fehlertext')' to object

Hatte die Abfrage auch so
if ( typeof document.getElementById('fehlertext') == "object" )

und so
if ((typeof document.getElementById('fehlertext')) == "object" )

probiert. Ebenso fehlerhaft.

Zu allem Überfluß meldet w3resource.com, dass man "Object" mit großem "O" schreibt. Andere Seiten tippen auf kleines "o". Aber da es ja auch mit != 'undefined' zum Fehler führt, muss das Problem woanders liegen. Nur wo?

Emso

[Siri]

Hallo,

if (document.getElementById('fehlertext')) {
 ...
}

Viele Grüße
Siri

[Emso]

Hallo Siri,

if (document.getElementById('fehlertext')) {
...
}

So hatte ich es ursprünglich. Läuft mit der Opera auch fehlerfrei, aber offenbar fehlerhaft mit dem IE 9 und IE 10. Deshalb habe ich recherchiert, wie man das Vorhandensein eines Objektes standardkonform abfragt. Und da wird immer typeof benutzt.

Dein Vorschlag (= mein alter Stand) müsste logischerweise zum Fehler führen, wenn document.getElementById('fehlertext') nicht vorhanden:

if (undefined)

Hatte ein vergleichbares Problem mit PHP. Nach Update auf eine neue Betriebssystem-Version poppten massig Warnungen auf, dass die Abfrage
if ($_POST['irgendwas'])

fehlerhaft ist. Richtig ist
if (defined("$_POST['irgendwas']"))

Emso

[Siri]

Hallo Siri,

if (document.getElementById('fehlertext')) {

So hatte ich es ursprünglich. Läuft mit der Opera auch fehlerfrei, aber offenbar fehlerhaft mit dem IE 9 und IE 10. Deshalb habe ich recherchiert, wie man das Vorhandensein eines Objektes standardkonform abfragt. Und da wird immer typeof benutzt.

kann ich nicht nachvollziehen, kann aber leider auch nur mit IE7 und IE8 testen.

	if (document.getElementById('fehlertext')) {  
          alert("exists");  
        } else {  
          alert("exists not");  
        }

document.getElementById('fehlertext') gibt null zurück, wenn das Element nicht existiert und dann ist die Bedingung "false". Schau mal, ob dein fehler nicht woanderst liegt.

Viele Grüße
Siri

[Matthias Apsel]

Om nah hoo pez nyeetz, Siri!

Schau mal, ob dein fehler nicht woanderst liegt.

Du kommst aus Halle/Saale.

Matthias

[Tabellenkalk]

Hello,

Du kommst aus Halle/Saale.

exists not

ich hatte bisher nur erkannt, dass er/sie nicht aus einem anglophonen Land stammt...

Gruß
Kalk

[Der Martin]

Hallo,

Schau mal, ob dein fehler nicht woanderst liegt.
Du kommst aus Halle/Saale.

nicht notwendigerweise, der Ausdruck "anderst" oder "woanderst", machmal sogar "Des machemer jetz ganz anderster" ist auch in vielen anderen Gegenden verbreitet.

Oder meintest du noch was anderes?

Ciao,
 Martin

[Matthias Apsel]

Om nah hoo pez nyeetz, Der Martin!

Schau mal, ob dein fehler nicht woanderst liegt.
Du kommst aus Halle/Saale.

nicht notwendigerweise, der Ausdruck "anderst" oder "woanderst", machmal sogar "Des machemer jetz ganz anderster" ist auch in vielen anderen Gegenden verbreitet.

Ich habe tatsächlich die Formulierung "anderst" nur im Hallenser Raum gehört. Dort musste ich 18 Monate meines Lebens verbringen. "Annerscher" kenne ich aus der Oberlausitz.

Matthias

[Siri]

Om nah hoo pez nyeetz, Siri!

Schau mal, ob dein fehler nicht woanderst liegt.

Du kommst aus Halle/Saale.

Boah! So eine Unterstellung! PLZ-Gebiet 71 gemischt mit jahrelangem PLZ-Gebiet 81 triffts besser :-)

[Der Martin]

Hallo,

Du kommst aus Halle/Saale.
Boah! So eine Unterstellung! PLZ-Gebiet 71 ...

huch, dann sind wir ja fast Nachbarn. ;-)

Ciao,
 Martin

[Siri]

Du kommst aus Halle/Saale.
Boah! So eine Unterstellung! PLZ-Gebiet 71 ...

huch, dann sind wir ja fast Nachbarn. ;-)

Ich würde dich über die S3 oder S4 (derzeit) gut erreichen ;-)

[Der Martin]

Hallo,

Du kommst aus Halle/Saale.
Boah! So eine Unterstellung! PLZ-Gebiet 71 ...
huch, dann sind wir ja fast Nachbarn. ;-)
Ich würde dich über die S3 oder S4 (derzeit) gut erreichen ;-)

dann befindest du dich momentan im Stuttgarter Innenstadtbereich, denn S3 und S4 begegnen sich nur auf dem Abschnitt zwischen Schwabstraße und Hauptbahnhof, fahren aber dann völlig getrennte Wege, bis sie ihre neuerdings gemeinsame Endstation erreichen (die ich vom Fenster meines Arbeitszimmers sehen kann) und sich dort wieder treffen.

Das passt dann aber nicht zum PLZ-Bereich 71. Logische Folgerung: Du bist gerade nicht zuhause. ;-)

Ciao,
 Martin

[Siri]

Ich würde dich über die S3 oder S4 (derzeit) gut erreichen ;-)

dann befindest du dich momentan im Stuttgarter Innenstadtbereich, denn S3 und S4 begegnen sich nur auf dem Abschnitt zwischen Schwabstraße und Hauptbahnhof, fahren aber dann völlig getrennte Wege, bis sie ihre neuerdings gemeinsame Endstation erreichen (die ich vom Fenster meines Arbeitszimmers sehen kann) und sich dort wieder treffen.

Gut kombiniert! Aber im Bereich Marbach/Winnenden kommen sich die beiden Linien auch wieder sehr nah.

[Der Martin]

Hallo,

Hatte ein vergleichbares Problem mit PHP. Nach Update auf eine neue Betriebssystem-Version poppten massig Warnungen auf, dass die Abfrage
if ($_POST['irgendwas'])

fehlerhaft ist. Richtig ist
if (defined("$_POST['irgendwas']"))

falsch, richtig ist das:

if (isset($_POST['irgendwas']))

Wobei das nutzlose Einbetten von Variablen in Strings anscheinend nicht auszurotten ist.

Ciao,
 Martin

[dedlfix]

Tach!

if (defined("$_POST['irgendwas']"))
falsch, richtig ist das:
if (isset($_POST['irgendwas']))
Wobei das nutzlose Einbetten von Variablen in Strings anscheinend nicht auszurotten ist.

Bei defined() wäre es aber im Prinzip richtig, da muss man den Konstantennamen angeben, nicht die Konstante selbst. Natürlich ist es trotzdem nicht richtig, defined() auf Variablen anwenden zu wollen.

dedlfix.

[Emso]

fehlerhaft ist. Richtig ist
if (defined("$_POST['irgendwas']"))

falsch, richtig ist das:

if (isset($_POST['irgendwas']))

Wobei das nutzlose Einbetten von Variablen in Strings anscheinend nicht auszurotten ist.

String wird zumindest bei defined laut PHP-Doku verlangt:
bool defined ( string $name )

Okay, bei isset nicht - da soll einer durchblicken ;-)
bool isset ( mixed $var [, mixed $... )]

Emso

[Der Martin]

Hallo,

if (document.getElementById('fehlertext')) {
...
}

So hatte ich es ursprünglich. Läuft mit der Opera auch fehlerfrei, aber offenbar fehlerhaft mit dem IE 9 und IE 10.

das muss eine andere Ursache haben; die Abfrage an sich ist korrekt und getElementyId() muss(!) auch im IE das erwartete Ergebnis liefern - nämlich entweder null oder ein DOM-Objekt.

Ciao,
 Martin

[molily]

Hallo,

if (document.getElementById('fehlertext')) {
...
}

So hatte ich es ursprünglich. Läuft mit der Opera auch fehlerfrei, aber offenbar fehlerhaft mit dem IE 9 und IE 10.

Es sollte auch im IE 9 und 10 funktionieren. Was passiert denn dort? Sind Exceptions auf der Konsole zu sehen? Welche?

Deshalb habe ich recherchiert, wie man das Vorhandensein eines Objektes standardkonform abfragt. Und da wird immer typeof benutzt.

Das kann man so nicht sagen. Wie man das Vorhandensein eines Objektes abfragt, hängt vom individuellen Fall ab. Siehe dazu meinen Artikel Objektabfragen und Fallunterscheidungen in JavaScript.

Im deinem Falle hast du einfach einen Funktionsaufruf und du brauchst lediglich den Rückgabewert prüfen. Der Rückgabewert von getElementById ist entweder null oder ein Elementobjekt. Null ist falsy (= konvertiert zu false, wenn ein Boolean erwartet wird), ein Elementobjekt ist truthy (= konvertiert zu true, wenn ein Boolean erwartet wird). Daher funktioniert folgendes:

var el = document.getElementById('foo');  
if (el) {…}

Wenn nicht, sollte die Ursache woanders liegen.

Dein Vorschlag (= mein alter Stand) müsste logischerweise zum Fehler führen, wenn document.getElementById('fehlertext') nicht vorhanden:

if (undefined)

Nein, das führt zu keinem Ausnahmefehler, der das Programm abbricht.

Bei solchen Abfragen gibt es hauptsächlich zwei Fälle, die einen Fehler auslösen:

• Der Zugriff auf nicht deklarierte Variable
    if (nichtExistenteVariable) wirft einen ReferenceError: nichtExistenteVariable is not defined
• Der Zugriff auf eine Eigenschaft von null/undefined
    window.nichtExistentesObjekt.eigenschaft wirft einen TypeError: Cannot read property 'eigenschaft' of undefined

Aber den Wert einer Expression/einer Variable zu prüfen, welche undefined oder null ist, wirft keine Exception.

Hatte ein vergleichbares Problem mit PHP. Nach Update auf eine neue Betriebssystem-Version poppten massig Warnungen auf, dass die Abfrage
if ($_POST['irgendwas'])

fehlerhaft ist. Richtig ist
if (defined("$_POST['irgendwas']"))

Ich glaube du suchst isset oder empty.

Grüße,
Mathias

[Emso]

sorry, vom erfolglosen Testen bin ich schon ganz konfus.

Wenn die HTML-Fehlermeldung angezeigt wurde, gibt es KEINE Javascript-Fehlermeldung. Die Anzeige wird wie gewünscht ausgeblendet.

Wenn die HTML-Fehlermeldung jedoch nicht gezeigt wird, also das <p> object NICHT vorhanden ist, gibt es den Javascript-Fehler.

[ichbinich]

Hallo,

Wenn die HTML-Fehlermeldung jedoch nicht gezeigt wird, also das <p> object NICHT vorhanden ist, gibt es den Javascript-Fehler.

Dann solltest du nicht nur überprüfen, ob es ein Object ist, sondern zusätzlich ob es überhaupt vorhanden ist...

vg ichbinich

[Emso]

Wenn die HTML-Fehlermeldung jedoch nicht gezeigt wird, also das <p> object NICHT vorhanden ist, gibt es den Javascript-Fehler.
Dann solltest du nicht nur überprüfen, ob es ein Object ist, sondern zusätzlich ob es überhaupt vorhanden ist...

Wie bitte ...
Wenn etwas NICHT vorhanden ist, kann es ein Objekt sein? Ich glaube, heute ist nicht mein Tag.

Emso

[unknown]

Aber da es ja auch mit != 'undefined' zum Fehler führt, muss das Problem woanders liegen. Nur wo?

Im lesen von Dokumentationen vermutlich.
Was getElementById im Fehlerfall liefert steht z.B. hier. Bei einem eindeutigen Wert im Fehlerfall kann man direkt auf diesen abprüfen.
Was typeof aber mit diesem Wert dann als Ergebniss liefert steht z.B. hier.

[Der Martin]

Hi,

angezeigte Fehlermeldung:
<p id="fehlertext" class="fehler" style="display:block">Fout: &nbsp; Login is mislukt &nbsp; </p>

ah, jullie praat Nederlands? :-)

bei Klick auf submit:

if ( typeof document.getElementById('fehlertext') != "undefined" )

{
    document.getElementById('fehlertext').style.display = 'none';
  }

  
Das wird so nichts. Eigentlich genügt als Abfrage ein  
  
  if (document.getElementById('fehlertext'))  
  
denn getElementById() liefert null, wenn kein entsprechendes Element im DOM gefunden wird, und null evaluiert im booleschen Kontext zu false. Und typeof(null) ist nicht "undefined", sondern "object", sagt Opera (hm, seltsam eigentlich, null ist ein Objekt?).  
Außerdem wäre es zur Optimierung sinnvoll, das Ergebnis dieser ersten Abfrage gleich zu speichern, so dass man im Rumpf der if-Abfrage nicht dieselbe DOM-Suche erneut durchführen muss. Also so:  
  
~~~javascript
  if (var e=document.getElementById('fehlertext'))  
 {  
   e.style.display = 'none';  
 }

Fehlermeldung der Opera:
Uncaught exception: TypeError: Cannot convert 'document.getElementById('fehlertext')' to object

Das deutet darauf hin, dass als Ergebnis von getElementById() eben doch null geliefert wird. Wann genau wird denn das entsprechende Script aufgerufen? Existiert das komplette Dokument da noch, oder wurde der Submit-Vorgang bereits angestoßen?

[...] muss das Problem woanders liegen. Nur wo?

Vermutlich im Vorhandensein bzw. Nichtvorhandensein eines Elements mit der ID "fehlertext" zum Zeitpunkt der Abfrage. Mehr kann ich aus dem bisher beschriebenen Szenario nicht ableiten.

Ciao,
 Martin

[Jeena Paradies]

Hallo,

if (var e=document.getElementById('fehlertext'))

{
   e.style.display = 'none';
}

  
Ui das ist aber hässlicher Programmierstil, besser und lesbarer:  
  
~~~javascript
var errortext = document.getElementById('errortext');  
  
if(errortext) {  
    errortext.style.display = 'none';  
}

Übrigens Emso, es ist schöner und lesbarer wenn alle Klassen- und Variablennamen, etc. einheitlich in Englisch sind, dann kann das Projekt auch später ohne Probleme jemand übernehmen der deiner Muttersprache nicht mächtig ist :-)

[Der Martin]

Hi,

if (var e=document.getElementById('fehlertext'))

{
   e.style.display = 'none';
}

>   
> Ui das ist aber hässlicher Programmierstil, besser und lesbarer:  
>   
> ~~~javascript

var errortext = document.getElementById('errortext');  

>   
> if(errortext) {  
>     errortext.style.display = 'none';  
> }

das empfinde ich genau umgekehrt: Deine Schreibweise macht mir beim Lesen und Nachvollziehen geringfügig mehr Mühe, weil _ein_ gedanklicher Schritt - nämlich das Holen, Merken und Abfragen eines Wertes - zerrissen wird.
Ich neige deswegen dazu, Programmcode so zu schreiben und zu strukturieren, dass im Idealfall jede Zeile auch einem gedanklichen Schritt entspricht. Das funktioniert nicht immer, aber meistens.

Übrigens Emso, es ist schöner und lesbarer wenn alle Klassen- und Variablennamen, etc. einheitlich in Englisch sind, dann kann das Projekt auch später ohne Probleme jemand übernehmen der deiner Muttersprache nicht mächtig ist :-)

Das ist allerdings wahr.

Ciao,
 Martin

[unknown]

if (var e=document.getElementById('fehlertext'))

{
   e.style.display = 'none';
}

> >   
> > Ui das ist aber hässlicher Programmierstil, besser und lesbarer:  
> >   
> > ~~~javascript

var errortext = document.getElementById('errortext');  

> >   
> > if(errortext) {  
> >     errortext.style.display = 'none';  
> > }

Wobei das var im if auch kein gültiger Code ist.

[Emso]

Hallo Jeena Paradies,

habe dieses Thema aus dem Fach-Faden mal ausgekoppelt, dort würde es die Diskussion verwässern.

Übrigens Emso, es ist schöner und lesbarer wenn alle Klassen- und Variablennamen, etc. einheitlich in Englisch sind, dann kann das Projekt auch später ohne Probleme jemand übernehmen der deiner Muttersprache nicht mächtig ist :-)

Eine Ansicht, über die ich immer wieder nachdenke. Würde jemand ein fremdes Projekt übernehmen? Nicht ausgeschlossen, aber unwahrscheinlich.

Meine Programme sind "sprachlos", enthalten nur die Verarbeitungslogik. Für die Ausgabe werden Platzhalterdateien in de, en, fr, nl oder pl herangezogen.

Welche dieser Sprachen sollte ich - als Deutscher - nun für Prozeduren- und Variablennamen im Logikteil verwenden?

Das Englische ist keinesfalls logischer als das Deutsche. Ich erinnere nur an den englischen Eiertanz bei CSS: padding - border - margin, um einen Rahmmen zu beschreiben.

In meinem Chor ist es "modern", englische Texte zu singen und auch meine Enkel sind geil auf englische Schlager. Aber wenn ich frage, um was es da geht bei dem Text, kommt nichts. Und ich wette eine Kiste Champagner, dass keine 20 Prozent unserer Chor-Zuhörer irgendeine Idee haben, was wir da so unverständlich rüberbringen wollen.

Im KLartext: Englisch rede ich mit Engländern oder ersatzweise mit anderen, die deutsch nicht verstehen. Aber etwas gaga war dieses englische Gespräch im Urlaub in Asien:

• Informationsaustausch über die Sehenswürdigkeiten, die man schon genossen hatte. Tipps über Restaurants und so weiter ... -

Dann die Frage: "From where do you come?" - "From Germany" - "Which town?" - "Brunswick" - "Oh, I'm coming near from Frankfurt, können wir jetzt auf deutsch weitermachen?"

Emso

[ichbinich]

Hallo,

Das Englische ist keinesfalls logischer als das Deutsche. Ich erinnere nur an den englischen Eiertanz bei CSS: padding - border - margin, um einen Rahmmen zu beschreiben.

Nur border beschreibt hierbei einen Rahmen.

vg ichbinich