Newsgroup: it.comp.lang.javascript
Titolo: metodo elegante per vedere se esiste un ID

if(document.getElementById('user_vote_'+username).id != undefined){
        setTimeout('location.reload(true)', 250);
}
funziona, ma se non esiste genera un warning. esiste un metodo più elegante
per stabilire l'esistenza di un Element?
preferirei non usare form.
grazie
-- 
rotolando sul pavimento che ride

 per stabilire l'esistenza di un Element?
 if(document.getElementById('user_vote_'+username)!= null)
'bye

 null
grazie lo provo. vediamo se genera l'eccezione.


 grazie lo provo. vediamo se genera l'eccezione.
has no properties.
effettivamente non č colpa di undefined o null.
non so. mi pare una cosa un po' sporca lasciarlo cosě.


 effettivamente non è colpa di undefined o null.
Hai riportato erroneamente il codice che ti ha dato Agostino. Lui ti ha
scritto:
 
	if(document.getElementById('user_vote_'+username)!= null)
Mentre, da come parli, secondo me hai aggiunto "id" alla fine, esattamente
come era nel tuo codice originale:
	if(document.getElementById('user_vote_'+username).id != undefined)
Insomma, hai solo sostituito null a undefined.
-- 
"E' un vero peccato che tutte le persone che sanno come far funzionare 
il Paese siano troppo occupate a guidare taxi o a tagliare capelli."
(George Burns)

 
mi vorrei percuotere la faccia, che figura...
grazie :)
-- 
 All those who believe in Telekinesis raise my hand.

 ZER0 wrote:
da qualche tempo sto' utilizzando spesso per queste cose il try{} 
catch(e) {}... in alcuni casi sembra migliorare il flusso del codice.
dite che è sbagliato?
simple_maL

 catch(e) {}... 
Primo, per queste cose mi pare decisamente sprecato. Hai già il metodo in
questione che ti ritorna "null" in caso non esista l'elemento, e questo
comportamento esiste proprio per poter fare il check; altrimenti avrebbero
direttamente rilanciato un eccezione in modo nativo.
Secondo, il try/catch non è supportato da alcuni browser. Che si tratti di
browser vecchi, o semplicemente testuali o di device portabili (vedasi
cellulari, pda..). Quindi un codice che fa uso di try/catch andrebbe in errore
automaticamente, perché verrebbe considerato un errore di sintassi. E se c'è
una cosa che non si dovrebbe mai fare, è far andare in errore un browser.
Per questo si deve stare attenti a come e quando lo si usa. In una intranet il
problema non si pone, mentre su web bisogna porre attenzione.
Terzo, notoriamente lo statement try/catch "rallenta" il codice. Non ho mai
fatto effettivi test su javascript (anche perché solitamente non si ha bisogno
di chissà che performance elevate), ma immagino che si applichi la stessa
logica.
In sintesi, ti direi di non usarlo a meno che non sia strettamente necessario.


 catch(e) {}... 
Primo, per queste cose mi pare decisamente sprecato. Hai già il metodo in
questione che ti ritorna "null" in caso non esista l'elemento, e questo
comportamento esiste proprio per poter fare il check; altrimenti avrebbero
direttamente rilanciato un eccezione in modo nativo.
Secondo, il try/catch non è supportato da alcuni browser. Che si tratti di
browser vecchi, o semplicemente testuali o di device portabili (vedasi
cellulari, pda..). Quindi un codice che fa uso di try/catch andrebbe in errore
automaticamente, perché verrebbe considerato un errore di sintassi. E se c'è
una cosa che non si dovrebbe mai fare, è far andare in errore un browser.
Per questo si deve stare attenti a come e quando lo si usa. In una intranet il
problema non si pone, mentre su web bisogna porre attenzione.
Terzo, notoriamente lo statement try/catch "rallenta" il codice. Non ho mai
fatto effettivi test su javascript (anche perché solitamente non si ha bisogno
di chissà che performance elevate), ma immagino che si applichi la stessa
logica.
In sintesi, ti direi di non usarlo a meno che non sia strettamente necessario,
almeno su web.
Almeno, di non usarlo laddove proprio se ne può fare a meno e - anzi - è
consigliato farne a meno (vedasi il check sugli elementi).


ZER0 wrote:
[CUT]
che bello quando risponde ZER0
ciao


ZER0 ha scritto:
[CUT]
opperbacco...
grazie mille ZERO, sinceramente non sapevo nulla di tutto ciò..
io l'ho visto usare regolarmente in alcuni script molto famosi e 
distribuiti online come completamente cross-browser e ho iniziato ad 
usarlo di conseguenza... putroppo non ho mai fatto studi seri in 
materia, tendo ad imparare nuove cose guardando codice qua e la...
Infatti mi son scritto una mia classe per usare l'oggetto XMLHTTP
prendendo spunto dalla rete e, come risultato, nell'istazione l'oggetto, 
ho usato:
if (window.XMLHttpRequest)
{
   // Mozilla, Safari,...
   JxHttpRequest = new XMLHttpRequest();
}
else if (window.ActiveXObject)
{
   // Internet Explorer
   try {
     JxHttpRequest = new ActiveXObject("Msxml2.XMLHTTP");
   } catch (e) {
     try {
       JxHttpRequest = new ActiveXObject("Microsoft.XMLHTTP");
     } catch (e) {}
   }
}
che a questo punto mi sa che dovrò cambiare...
hai qualche suggerimento? :)
P.S. cmq spero nel futuro aumenti la compatibilità di questa sintassi 
perchè mi sembra molto interessante e produttiva...
simple_maL

 perchè mi sembra molto interessante e produttiva...
try/catch/finally/throw sono fenomenali, e vanno usati. 
Ma nel giusto contesto e nel giusto modo.
Io ad esempio li ho usati anche per la validazione delle form, e mi hanno
semplificato la vita non poco, rendendo inoltre il codice più leggibile e
gestibile. Ma in un applicativo intranet. Non in un sito web, che dovrebbe
essere accessibile e fruibile a prescindere dal dispositivo.
