Domanda su [set|clear]Timeout

Ciao a tutti,

scusate, non ho saputo mettere un Subject migliore

vorrei permettere l'evocazione multipla di una funzione con l'esecuzione
ritardata che elimina il lancio schedulato in precedenza
il tutto scrivendo una sola funzione

quello a cui ho concepito è questo:

function action( )
{
function myAct( )
{
alert( 'ciao' );
action.timerID = null;
}
if( action.timerID )
{
clearTimeout( action.timerID );
action.timerID = null;
}

action.timerID = setTimeout( myAct, 500 );
}

e come si può vedere utilizzo una variabile "statica privata" per salvare
il riferimento del timeout, evitando variabili globali e/o chiusure, pero'
"chiudo" myAct() che è la vera azione che prima o poi viene lanciata

Cosa dite, c'è qualche altro modo "carino" per fare questa cosa?

On Fri, 6 Jun 2008 10:32:56 +0200, Ugo wrote:

vorrei permettere l'evocazione multipla di una funzione con l'esecuzione
ritardata che elimina il lancio schedulato in precedenza
il tutto scrivendo una sola funzione

quello a cui ho concepito è questo:
[snip]
e come si può vedere utilizzo una variabile "statica privata" per salvare
il riferimento del timeout, evitando variabili globali e/o chiusure

E quella che cos'è, se non una closure?

pero' "chiudo" myAct()

Per l'appunto.

Cosa dite, c'è qualche altro modo "carino" per fare questa cosa?

Ragionare a oggetti invece che in termini di funzioni, ad esempio?

--
~ "Quando i morti camminano, signori, bisogna smettere di uccidere.
O si perde la guerra." (Zombie)

[cut]

Ragionare a oggetti invece che in termini di funzioni, ad esempio?

:"(
E' una persecuzione anche in questo caso?

Ok, cmq a dire la verità ci avevo provato, pero' a parte i diversi approci
che immagino che ci possono essere, io mi trovo in difficoltà all'ultimo
quando devo associare all'event handler il risultato di un metodo del mio
oggetto, e cioè

supponiamo che debba agire sull'onclick di un bottone
ad un certo punto dovrò fare qualcosa tipo:
document.getElementById( 'btn1' ).onclick = a.action( );

il chè andrebbe anche,
però ho come minimo fatto una chiusura sul this

On Fri, 6 Jun 2008 11:38:56 +0200, Ugo wrote:

Ragionare a oggetti invece che in termini di funzioni, ad esempio?

:"(
E' una persecuzione anche in questo caso?

Se la prendi in questo modo, evito di farti un reply: hai fatto una
domanda, ed io ho risposto... tutto qua.

Ok, cmq a dire la verità ci avevo provato, pero' a parte i diversi approci
che immagino che ci possono essere, io mi trovo in difficoltà all'ultimo
quando devo associare all'event handler il risultato di un metodo del mio
oggetto,

Già stai cambiando le carte in tavola. Un conto è se lavori solo su
oggetti JS, un altro è se mischi il tutto con oggetti DOM. Cambiano
gli approcci: ciò che è consigliato o si può fare in un caso, non è
detto che sia consigliato o che si possa fare nell'altro (a livello
crossbrowser, soprattutto.. Se IE non ci fosse, sarebbe decisamente
tutt'altro paio di maniche).

supponiamo che debba agire sull'onclick di un bottone
ad un certo punto dovrò fare qualcosa tipo:
document.getElementById( 'btn1' ).onclick = a.action( );

Semplicemente, è sbagliato un approccio del genere. Se si tratta di
applicazioni web, devi cambiare totalmente modo di pensare. Ragiona
a oggetti, non ha singoli elementi e funzioni.

però ho come minimo fatto una chiusura sul this

Premesso che personalmente le closure le considero uno strumento da
utilizzare solo se si è ben consapevoli di tutte le implicazioni; e
- soprattutto - mai abusarne; se le closure vengono effettuate solo
su oggetti JS le si possono usare più in tranquillità. E' quando si
ha a che fare con il DOM (e soprattutto con IE) che bisogna andarci
con i piedi di piombo (nonostante molti leak siano stati corretti).

--
~ Always remember you're unique, just like everyone else.

[cu]

io mi trovo in difficoltà all'ultimo quando devo associare
all'event handler il risultato di un metodo del mio oggetto,

Già stai cambiando le carte in tavola. Un conto è se lavori solo su
oggetti JS, un altro è se mischi il tutto con oggetti DOM.

Ops, ho notato che ho ommesso che il tutto viene evocato attraverso
un'onclick...

[cut]

document.getElementById( 'btn1' ).onclick = a.action( );
Semplicemente, è sbagliato un approccio del genere. Se si tratta di
applicazioni web, devi cambiare totalmente modo di pensare.

(Premesso che sto seriamente valutando di farti un'offerta che non puoi
rifiutare, richiedendoti docenze private - ne parlavo giusto ieri a mia
moglie, e quando vengono fuori queste cose ne sento sempre più
l'esigenza...)

Ragiona a oggetti, non ha singoli elementi e funzioni.

allora, ci provo:
dovrei pensare ad un oggetto che genericamente ritarda delle esecuzioni,
queste esecuzioni possono essere personalizzate estendendo questo oggetto e
all'oggetto instanziato da qualche parte gli si passa l'informazione di
quali "eventi DOM" va applicata la suddetta azione estensa (passando
id/reference ed evento o qualcosa del genere)?

una cosa strutturata in questo modo è più OOP?
altrimenti come può essere orientata ad oggetti questa cosa?

io ho un tot di eventi da gestire che lanciano in esecuzione un'azione che
viene "zompata" da un'eventuale altra occorsa prima che la precendete fosse
eseguita
quando mi dici, "pensala ad oggetti", mi sa' che ho una serie difficoltà,
hai tempo di descrivermi il processo mentale che mi dovrebbe venire anche
più naturale a cui cercherò poi di affiancare una soluzione?

Grazie

On Fri, 6 Jun 2008 12:36:18 +0200, Ugo wrote:

io mi trovo in difficoltà all'ultimo quando devo associare
all'event handler il risultato di un metodo del mio oggetto,

Già stai cambiando le carte in tavola. Un conto è se lavori solo su
oggetti JS, un altro è se mischi il tutto con oggetti DOM.

Ops, ho notato che ho ommesso che il tutto viene evocato attraverso
un'onclick...

Aspetta, non era una "critica". Nel senso, non dovevi leggerla come
"ehy, non hai detto le cose come stanno". Era per sottolineare come
non è detto che una metodologia che viene usata in un caso si possa
usare anche nell'altro.
Come ti ho detto personalmente le closure le uso col contagocce, ma
quelle che uso non mi faccio problemi a usarle se rimango in ambito
JS; mentre ancora ci penso un po' su se c'è il DOM di mezzo.

Semplicemente, è sbagliato un approccio del genere. Se si tratta di
applicazioni web, devi cambiare totalmente modo di pensare.

Ragiona a oggetti, non ha singoli elementi e funzioni.

allora, ci provo:
dovrei pensare ad un oggetto che genericamente ritarda delle esecuzioni,
queste esecuzioni possono essere personalizzate estendendo questo oggetto e
all'oggetto instanziato da qualche parte gli si passa l'informazione di
quali "eventi DOM" va applicata la suddetta azione estensa (passando
id/reference ed evento o qualcosa del genere)?

Non mi sono spiegato bene, riformulo. Mi riferivo proprio al metodo
in sè, non al caso specifico.
Ovvero, su come basare l'interazione DOM/JS. Come mai un oggetto JS
dovrebbe "conoscere" una data istanza di un oggetto DOM? Ovviamente
anche viceversa: rispondendo a queste domande, inizi a definire ciò
che lega i due oggetti, la loro "relationship", e poi ciò che nella
OOP è un argomento delicato: la responsabilità degli oggetti. A chi
compete cosa, in una "relazione".

Vedila così: si crea una relazione tra oggetto DOM e JS, quando uno
deve conoscere l'istanza dell'altro. A quel punto, va cambiato modo
di pensare.

quando mi dici, "pensala ad oggetti", mi sa' che ho una serie difficoltà,
hai tempo di descrivermi il processo mentale che mi dovrebbe venire anche
più naturale a cui cercherò poi di affiancare una soluzione?

Eh.. è più facile a farsi che a dirsi; quello a cui mi riferisco io
sono pratiche generiche di design. Come ho scritto poc'anzi, non si
tratta del caso in sè.

(Premesso che sto seriamente valutando di farti un'offerta che non puoi
rifiutare,

Non rifiuto solo quel genere di offerte che contemplano donzelle, e
magari bionde con gli occhi azzurri.. il resto è sempre discutibile
invece. :P

Tornando seri, anni fa c'era in ballo qualcosa del genere, ma non è
una cosa facile da farsi, né da organizzare - in gruppi intendo - e
si perse il momento.

Tra l'altro adesso sto cercando di dedicarmi ad altro (Flex/AIR), e
avrei poco tempo.
Inoltre, le cose lato web stanno per cambiare in modo rilevante, un
po' come successe ai tempi di IE4/NS4.. E ci sarà parecchio da fare
e da studiare.

--
~ Chi segue gli altri, non arriva mai primo.

[cut]

Era per sottolineare come non è detto che una metodologia che viene
usata in un caso si possa usare anche nell'altro.

ok

[cut]

Ovvero, su come basare l'interazione DOM/JS. Come mai un oggetto JS
dovrebbe "conoscere" una data istanza di un oggetto DOM? Ovviamente
anche viceversa: rispondendo a queste domande, inizi a definire ciò
che lega i due oggetti, la loro "relationship", e poi ciò che nella
OOP è un argomento delicato: la responsabilità degli oggetti. A chi
compete cosa, in una "relazione".

Mmmm, ti seguo

Vedila così: si crea una relazione tra oggetto DOM e JS, quando uno
deve conoscere l'istanza dell'altro. A quel punto, va cambiato modo
di pensare.

inizio a capire

quando mi dici, "pensala ad oggetti", mi sa' che ho una serie difficoltà,
hai tempo di descrivermi il processo mentale che mi dovrebbe venire anche
più naturale a cui cercherò poi di affiancare una soluzione?

Eh.. è più facile a farsi che a dirsi; quello a cui mi riferisco io
sono pratiche generiche di design. Come ho scritto poc'anzi, non si
tratta del caso in sè.

ho, capito
e visto che ora rischio l'ot, per caso avresti dei link da suggerire che mi
aiutino?
inutile dire che un esempietto esplicativo di un qualsivoglia oggetto che
associ ad un evento del DOM un proprio metodo sarebbe ben gradito, visto
che tra l'altro è più "più facile a farsi che a dirsi" :P

Tornando seri, anni fa c'era in ballo qualcosa del genere, ma non è
una cosa facile da farsi, né da organizzare - in gruppi intendo -

io, invece, no

[cut]

Inoltre, le cose lato web stanno per cambiare in modo rilevante, un
po' come successe ai tempi di IE4/NS4.. E ci sarà parecchio da fare
e da studiare.

io non ci trovo niente da sorridere
non dire così, che mi viene la depressione

Ugo ha scritto:

[cut]
Inoltre, le cose lato web stanno per cambiare in modo rilevante, un
po' come successe ai tempi di IE4/NS4.. E ci sarà parecchio da fare
e da studiare.

io non ci trovo niente da sorridere
non dire così, che mi viene la depressione

male: dovresti esserne affascinato invece...

in questo "mestiere" fossilizzarsi vuol dire restare fregati, ogni
tecnologia e' "transitoria", apprenderla deve insegnarti a riconoscere quei
"patterns" comuni che invece non cambiano mai, che ti permetteranno di
imparare facilmente qualunque novita', e contemporaneamente, evitare che le
sinapsi del tuo cervello si blocchino, mantenendo una mente agile.

sembra facile detta cosi', comunque il segreto e' "tutto" qui

--
Piu' che ecoballe c'erano tante balle e basta.

On Fri, 6 Jun 2008 18:34:27 +0200, Ugo wrote:

[cut]

inizio a capire

Eh.. è più facile a farsi che a dirsi; quello a cui mi riferisco io
sono pratiche generiche di design. Come ho scritto poc'anzi, non si
tratta del caso in sè.

ho, capito
e visto che ora rischio l'ot, per caso avresti dei link da suggerire che mi
aiutino?

Se devo essere sincero, no. Io quello che so in materia l'ho appreso
in parte studiando sui libri, e in parte con la pratica, sviluppando
con linguaggi OOP che ti spingevano ad entrare per forza di cose, in
una certa mentalità - sia per i loro pregi che per i loro difetti.

L'unico buon consiglio che ti posso dare, te l'ho già dato: acquista
il libro della GoF sui DP.
Magari all'inizio ti può risultare un po' ostico, ma indubbiamente è
ciò che ti serve.

inutile dire che un esempietto esplicativo di un qualsivoglia oggetto che
associ ad un evento del DOM un proprio metodo sarebbe ben gradito,

E allora non hai "iniziato a capire" una beneamata. Riassumendo:
a) Non esiste un approccio unico alla questione e dipende da diversi
fattori.
b) Questo approccio cambia anche in base alla natura e relazione dei
due elementi in soggetto.
c) Non è detto che un approccio usato in certo ambito si debba usare
anche in un altro.
d) Si tratta di pratiche di design e quindi esulano dal contesto DOM
o JS nello specifico.
e) Conseguentemente agli punti, per scriverti un codice che illustri
un'eventuale associazione dei due oggetti in ottica di OOP; andrei a
generare una struttura intera di una pseudo-applicazione.

che tra l'altro è più "più facile a farsi che a dirsi" :P

Quando lo sai fare, ovviamente.

Inoltre, le cose lato web stanno per cambiare in modo rilevante, un
po' come successe ai tempi di IE4/NS4.. E ci sarà parecchio da fare
e da studiare.

io non ci trovo niente da sorridere
non dire così, che mi viene la depressione

Vale anche per me la risposta che ti ha dato Claudio, sebbene un po'
ti capisca.

--
~ "Le leggi sono come le ragnatele:
abbastanza forti per catturare i deboli,
troppo deboli per trattenere i forti."
(Anacarsi lo Scita)

On Fri, 6 Jun 2008 18:57:51 +0200, mastro delphine wrote:

male: dovresti esserne affascinato invece...

in questo "mestiere" fossilizzarsi vuol dire restare fregati, ogni
tecnologia e' "transitoria", apprenderla deve insegnarti a riconoscere quei
"patterns" comuni che invece non cambiano mai, che ti permetteranno di
imparare facilmente qualunque novita', e contemporaneamente, evitare che le
sinapsi del tuo cervello si blocchino, mantenendo una mente agile.

Concordo appieno; chi mi conosce lo sa che sfondi una porta aperta.

Però, diciamocelo: chi tra di noi non ha mai pensato che sarebbe stato
decisamente meglio se fossimo andati a coltivar patate? Oppure, aprire
un bar sulle sponde di una qualche spiaggia; o che, dopotutto, fare un
lavoro come l'idraulico o l'elettricista sarebbe stato meno stressante
e ben più remunerativo di questo...

Delle volte penso che questo lavoro sia un po' "malato". E che seppure
ci stai attento, t'ammali un po' anche tu.
E se a qualcuno ogni tanto viene la depressione pensandoci... beh, si,
lo capisco un po'.

--
~ "Io rispetto molto la stupidità umana.
E' la sola cosa che mi dia un'idea dell'eternità."
(Voltaire)