Inserire funzione su Onclick

[webking2003]

Ciao Ragazzi ho un piccolo problema... ho una serie di id in un' array e vorrei inserire dinamicamente questi id sugli onclick di elementi creati col dom in un FOR

var linkForLi = document.createElement('a');				  linkForLi.appendChild(document.createTextNode(usernameArray[i]));
linkForLi.href = '#no-up';
var idToSend = idArray[i];
linkForLi.onclick = function(){ InsertDelUser.inserimentoUtenti(idToSend) };

fate conto che questo codice sta in un for e che in idArray ho degli ID quindi vorrei associare allì onclick di quel link

linkForLi.onclick = function(){ InsertDelUser.inserimentoUtenti(idToSend) };

quel determinato ID presente nell'array solo che quando vado a cliccare mi da sempre lo stesso ID ovvero l'ultimo....come mai?

[carlomarx]

È un “problema” classico di javascript. Succede perché assegnare n volte una funzione a qualcosa non significa creare n funzioni diverse. Tu stai assegnando a tutti i tuoi elementi la stessa funzione, che attingerà alle variabili che si trova intorno per come sono al momento in cui viene eseguita. L'unico modo per creare con un ciclo n funzioni realmente diverse è col costruttore di funzioni new Function("[CORPO DELLA FUNZIONE"]), ma è un metodo dispendioso e inutile per casi come il tuo, per i quali esistono soluzioni molto più semplici. La più sicura è l'assegnazione di un id ai tuoi elementi. Si tratta della soluzione più supportata (funzionerà con TUTTI i browsers):

function tuaFunzione() { InsertDelUser.inserimentoUtenti(this.id) }


var linkForLi = document.createElement('a');
linkForLi.appendChild(document.createTextNode(usernameArray[i]));
linkForLi.href = '#no-up';
linkForLi.id = idArray[i];
linkForLi.onclick = tuaFunzione;

Un'altra possibilità è quella di adoperare i metodi getUserData e setUserData, che hanno il vantaggio di poter contenere anche numeri, booleani, etc., a differenza degli id che possono contenere solo stringhe. Il problema però è che non sono supportati dai browsers più vecchi Di fatto si tratta del metodo "ufficiale" per risolvere questo tipo di problemi:

function tuaFunzione() { InsertDelUser.inserimentoUtenti(this.getUserData("idToSend")) }


var linkForLi = document.createElement('a');
linkForLi.appendChild(document.createTextNode(usernameArray[i]));
linkForLi.href = '#no-up';
linkForLi.setUserData("idToSend", idArray[i], null);
linkForLi.onclick = tuaFunzione;

Un'ultima possibilità è quella di usare l'operatore let, che è in grado di dichiarare delle variabili in un nuovo scope. Come ti accorgerai dalla colorazione in rosso, si tratta di uno standard relativamente recente, dovrai quindi specificare la versione di javascript all'interno del tag <script> (<script type="text/javascript;version=1.7">):

<script type="text/javascript;version=1.7">
var linkForLi = document.createElement('a');
linkForLi.appendChild(document.createTextNode(usernameArray[i]));
linkForLi.href = '#no-up';
let idToSend = idArray[i];
linkForLi.onclick = function () { InsertDelUser.inserimentoUtenti(idToSend) };
</script>

[webking2003]

Sei stato veramente formidabile, grazie mille!

Ho usato il metodo di passare l' ID alla funzione tramite this.id e poi per una cosa che mi serviva con substr mi sono recuperato anche il valore dell'id !

Quello che mi hai scritto me lo stampo perchè è una grande spiegazione!

Grazie ancora

[TrueLies]

Scusatemi, ma date le diverse opzioni (da che programmazione è programmazione, c'è sempre più di un modo di fare le cose) perchè non analizzare quale soluzione è migliore anzichè presentarle come indiscriminatamente equivalenti?

Ora: il metodo tradizionale funziona su qualsiasi browser dell' universo usato da esseri umani.

A tal punto, questa considerazione dovrebbe già essere sufficiente a dirci che è quello l'approccio procedurale da usare.

Non si capisce infatti perchè in un caso del genere si dovrebbe usare setUserData: quello che dobiamo assegnare è un valore stringa -e qui già uno dei "vantaggi" di setUserData si perde del tutto; poi dobbiamo settare un id, proprietà invero spesso assai fondamentale per uso DOM, per cui per quale motivo utilizzare setUserData il quale ha lo scopo di non coinvolgere direttamente il DOM -si perde un secondo "vantaggio" di setUserData.

A questo punto, perchè proporlo? Cioè, magari c'è un motivo assolutamente fondamentale per cui in questo caso sarebbe consigliabile usarlo ma a me sfugge e allora spiegatemelo. Ma se il motivo non c'è, allora spieghiamo anche quale è l'uso appropriato di setUserData anzichè impiegarlo solo perchè si può.

Quanto all' operatore let, il suo unico vantaggio è di permettere una inzializzazione in uno scope volatile. Nel contesto in cui è inserito qui, o espleta lo stesso ruolo che impiegare var, o contamina comunque lo scope della window.

Cioè: se i vantaggi nel caso specifico non ci sono, perchè non andare direttamente al metodo standard anzichè impiegare caratteristiche nuove pensate per scopi e finalità molto specifiche e limitate e che dunque sarebbe più sensato riservare a quei casi - o si smarrisce completamente il senso delle cose.

Per carità, io non ho nulla in contrario ad usare una sintassi perchè magari ci piace di più e farne una questione di programmazione estetica - è che siccome sono abituato a programmare in modo diverso, cioè ad usare le cose quando servono (e anche lì siccome siamo umani è sempre possibile sbagliare), mi chiedevo se magari vi era in questo contesto un qualcosa che mi sfugge alla luce del quale invece l'uso delle alternative si fa non solo pertinente ma necessario e funzionalizzato agli scopi per soddisfare i quali le alternative sono nate.

Grazie a chi vorrà rispondere (peccato non è oggetto di scommesse alla lottomatica!)
ciau

[carlomarx]

Originariamente inviato da TrueLies
Grazie a chi vorrà rispondere (peccato non è oggetto di scommesse alla lottomatica!)
ciau

Che ci vuoi fare, intervieni alle discussioni a cui sono iscritto io. Anche se non guardassi il forum mi arriverebbe comunque una notifica via email

Originariamente inviato da TrueLies
Scusatemi, ma date le diverse opzioni (da che programmazione è programmazione, c'è sempre più di un modo di fare le cose) perchè non analizzare quale soluzione è migliore anzichè presentarle come indiscriminatamente equivalenti?

Nessuno ha mai detto che sono equivalenti.

Originariamente inviato da TrueLies
Ora: il metodo tradizionale funziona su qualsiasi browser dell' universo usato da esseri umani.

A tal punto, questa considerazione dovrebbe già essere sufficiente a dirci che è quello l'approccio procedurale da usare.

Cosa intendi per "metodo tradizionale"?

Originariamente inviato da TrueLies
Non si capisce infatti perchè in un caso del genere si dovrebbe usare setUserData: quello che dobiamo assegnare è un valore stringa -e qui già uno dei "vantaggi" di setUserData si perde del tutto; poi dobbiamo settare un id, proprietà invero spesso assai fondamentale per uso DOM, per cui per quale motivo utilizzare setUserData il quale ha lo scopo di non coinvolgere direttamente il DOM -si perde un secondo "vantaggio" di setUserData.

A questo punto, perchè proporlo? Cioè, magari c'è un motivo assolutamente fondamentale per cui in questo caso sarebbe consigliabile usarlo ma a me sfugge e allora spiegatemelo. Ma se il motivo non c'è, allora spieghiamo anche quale è l'uso appropriato di setUserData anzichè impiegarlo solo perchè si può.

Perché ci sono casi in cui gli Id sono già "occupati" per altri usi o perché non dobbiamo salvare solo un'informazione, ma molte informazioni, o semplicemente perché è molto meno dispendioso leggere un booleano che convertire una stringa in booleano con Boolean("[STRINGA VUOTA/OPPURE NO]"). Ripeto, è una proprietà che è stata inventata apposta per questi usi.

Originariamente inviato da TrueLies
Quanto all' operatore let, il suo unico vantaggio è di permettere una inzializzazione in uno scope volatile. Nel contesto in cui è inserito qui, o espleta lo stesso ruolo che impiegare var, o contamina comunque lo scope della window.

È vero che tra i tre è il metodo più dispendioso (si crea uno scope per ogni ciclo &ndash; ma attenzione! uno scope non è una closure, è qualcosa in meno in termini di dispendio di risorse!). Ma non espleta lo stesso ruolo che espleterebbe var. Con var semplicemente non funzionerebbe.

Originariamente inviato da TrueLies
Cioè: se i vantaggi nel caso specifico non ci sono, perchè non andare direttamente al metodo standard anzichè impiegare caratteristiche nuove pensate per scopi e finalità molto specifiche e limitate e che dunque sarebbe più sensato riservare a quei casi - o si smarrisce completamente il senso delle cose.

Quale sarebbe il metodo standard, quello delle closures??

Originariamente inviato da TrueLies
Per carità, io non ho nulla in contrario ad usare una sintassi perchè magari ci piace di più e farne una questione di programmazione estetica - è che siccome sono abituato a programmare in modo diverso, cioè ad usare le cose quando servono (e anche lì siccome siamo umani è sempre possibile sbagliare), mi chiedevo se magari vi era in questo contesto un qualcosa che mi sfugge alla luce del quale invece l'uso delle alternative si fa non solo pertinente ma necessario e funzionalizzato agli scopi per soddisfare i quali le alternative sono nate.

Continui a parlare di estetica, ma ti assicuro che passo molto tempo a esaminare la performatività e il dispendio di memoria delle tante risorse che offre javascript.

[carlomarx]

Originariamente inviato da TrueLies
Ora: il metodo tradizionale funziona su qualsiasi browser dell' universo usato da esseri umani.

P.S. Il mio professore di filosofia al liceo non faceva altro che dirci in continuazione di diffidare di chi dice che bisogna fare le cose «perché si è sempre fatto così». Javascript è un linguaggio molto più complesso di quello che appare, il 99% di chi lo usa non ha la più pallida idea di come funzioni l'interprete e, visto il fatto che la neccessità di usarlo è davvero vasta per un linguaggio di programmazione (ormai internet è un mezzo di massa), è molto facile che si diffondano delle abitudini improprie e che queste si affermino in breve tempo come "la norma". Un esempio abominevole è l'uso delle closures per risolvere casi come questo &ndash; il famigerato currying, gli venisse un colpo all'idiota che ha proposto una soluzione del genere! &ndash; oppure &ndash; ma si parla di un male minore &ndash; l'uso del doppio uguale, nato per scopi ben precisi e divenuto l'operatore di comparazione di uguaglianza ufficiale "de facto" di javascript. Ma ti potrei fare molti altri esempi di "cattive abitudini". Si tratta in tutti i casi di soluzioni proposte da chi ha poca o nessuna conoscenza di Javascript e presto diffusesi come la norma semplicemente perché troppo faticoso cercare soluzioni alternative o, peggio, perché non ci si rendeva conto dell'impatto negativo nel dispendio di memoria (le closures tenute aperte sono in assoluto la cosa più dispendiosa che esista in javascript &ndash; a parità di righe di codice ovviamente).

Ma quello che mi fa rabbia è che tutte le volte che rispondi alle mie argomentazioni te la prendi con chi utilizza codice "nuovo" (ma siamo sicuri?) "senza spirito critico", per poi proporre però le soluzioni "tradizionali acritiche" (tipo la preallocazione degli array), spesso sbagliate e nate da chi non ha piena conoscenza di js, contro la cui ulteriore diffusione chi conosce un po' più a fondo un interprete si dovrebbe battere. Fossi in te ci penserei su almeno un po'&hellip;

P.S. SpiderMonkey e Webkit (gli interpreti di ff e chrome e safari) sono open source ed entrambi cercano di rispettare le direttive ecmascript e w3c nei modi più rigorosi. Di SpiderMonkey esiste una copiosissima documentazione (https://developer.mozilla.org/en/SpiderMonkey). Fossi in te, a questo punto, mi darei una bella spulciatina ai sorgenti scritti in C/C++: è il modo migliore per capire davvero a fondo cos'è javascript&hellip;
&hellip;si sa mai, arrivasse l'illuminazione sulla via di Damasco