Newsgroup: it.comp.lang.javascript
Titolo: innerHTML o CreateElement

ciao, volendo modificare il dom a mio piacimento, ho notato che č possibile
(e funziona direi) fare un InnerHTML del tipo: 
var myArray = old_tags.split(';');
var tags = "";
for (var i = 0;i<myArray.length;i++)
{
  if(myArray[i]!=""){
   tags = tags+"<a href=\"/tag/"+myArray[i]+"\">"+myArray[i]+"</a> ";
}
var field = document.getElementById(what);
field.innerHTML = tags;
essendo io un caprone in Javascript. mi chiedo, č deprecabile quello che ho
fatto e sarebbe meglio creare un elemento "A" per ogni i dell'array?
spero di essermi spiegato,
Grazie mille
-- 
Vedo gli amici ancora sulla strada, loro non hanno fretta,
rubano ancora al sonno l'allegria all'alba un po' di notte:
e poi la luce, luce che trasforma il mondo in un giocattolo.
Faremo gli occhiali cosě, Faremo gli occhiali cosě!

 fatto e sarebbe meglio creare un elemento "A" per ogni i dell'array?
innerHTML NON è standard ma è gestito da tutti i browser moderni...vedi te.
C'è sempre il rischio che in futuro qualche browser non lo supporti più ma,
in tal caso, si potrà fare un prototype per simularlo...
Io uso innerhTML e non createElement, ma la scelta è personale (è più
comodo ma non è standard, sostanzialmente).
-- 
"Ti sei salvato
 o sei entrato in banca pure tu?"
									    A.V.

 fatto e sarebbe meglio creare un elemento "A" per ogni i dell'array?
Nel tu caso, sarebbe preferibile creare un elemento "A" e aggiungerlo al
document, piuttosto che usare innerHTML.
Al di là del fatto che non fa parte di alcuno standard, l'innerHTML è un
sistema un po' brutale e "sporco", similmente al document.write. Non è
strutturato, non hai un controllo sugli oggetti in quanto sono mere stringhe
(che potrebbero anche essere sintatticamente scorrette).
E' generalmente preferibile utilizzare le API del DOM: sono standard, ed è più
facile scrivere codice leggibile, manutenibile e riusabile.
Ho detto "generalmente": questo perché ci sono dei casi in cui invece è più
indicato l'uso di innerHTML.
Del resto, tutto dipende dal lavoro che si deve fare ("the right tool for the
right job").
Il caso in cui hai *effettivamente* una stringa di cui fare un output (che non
è il tuo caso), e tale stringa contiene parecchi tag HTML. Spesso tale stringa
è recuperata dinamicamente, magari da una richiesta remota o da file. Quindi
non sta *fisicamente* dentro il codice js (ergo, non lo "sporca").
Un'altro caso, in verità legato parzialmente al precedente, è quando hai
bisogno di performance migliori: innerHTML è più veloce dell'uso delle DOM
API. Se devi inserire in un elemento un codice che contiene parecchi tag e/o è
molto lungo, allora usa innerHTML.
Un esempio classico: visualizzare una TABLE con molte righe e colonne, magari
recuperata tramite XmlHttpRequest. E' più veloce farti restituire direttamente
il codice HTML, e inserirlo tramite innerHTML piuttosto che farti generare un
XML da poi ciclare e creare la tabella e le sue righe tramite le DOM API
(tralascio la questione XSLT, perché non è indicata da fare client-side).
Non c'è paragone.
Come puoi vedere dall'ultimo esempio, per ricollegarci al discorso iniziale,
usando innerHTML in quel modo perdi in riusabilità e modularità: difatti, se
invece di codice HTML avessi fatto restituire dalla chiamata server un codice
XML, dando una struttura adeguata, sarebbe risultato più generico e
riutilizzabile da qualsiasi altro software.
Mentre, restituendo direttamente una TABLE, leghi il risultato alla sintassi
HTML e ottimizzerai il risultato per la tua applicazione.
Quindi, l'uso o meno di un certo strumento o approccio, dipende molto dal
contesto in cui siamo, e dal risultato che vuoi ottenere: se la chiamata
server è fine all'applicazione e non verrà mai usata per altri scopi, è
corretto ottimizzarne le performance, anche a discapito di una minore
riusabilità. Viceversa, se la velocità non è critica - o semplicemente è
sufficiente quella che si ha utilizzando le DOM API - e si ha una buona
probabilità che il risultato della chiamata server possa essere riutilizzato
altrove, è bene puntare sulla riusabilità anche se questa può minare un poco e
performance.
Scusa se mi sono dilungato, soprattutto nell'ultimo tratto, su questioni che
esulavano la tua richiesta nello specifico.
Ma ho preferito cogliere l'occasione per approfondire la tematica sotto un po'
tutti gli aspetti.
-- 
- E.. lei è mestruata al momento?
- Ma scusi questo che c' entra??
- Si inchini alla scienza!

 Scusa se mi sono dilungato
E' vero: in quanto a logorrea non temi nessuno :)
-- 
Nando [?]
Ex-Apostolo della Ex-Prova

 E' vero: in quanto a logorrea non temi nessuno :)
Ghgh. Te l'avevo detto. Almeno, per quanto riguarda questo contesto. :)
-- 
- Lei ha precedenti di pazzia in famiglia?
- Mio nonno credeva d' essere San Giuseppe...
- Io ci metterei un bel SI!

 
immensamente grato per la spiegazione.
l'applicativo potrà cambiare e comincio a valutare (grazie alla tua
spiegazione) che sia molto meglio usare le api per il DOM.
grazie ancora
-- 
Vedo gli amici ancora sulla strada, loro non hanno fretta,
rubano ancora al sonno l'allegria all'alba un po' di notte:
e poi la luce, luce che trasforma il mondo in un giocattolo.
Faremo gli occhiali così, Faremo gli occhiali così!