[PIPPE MENTALI] gestione degli eventi in PHP

[andr3a]

[supersaibal]Originariamente inviato da Fabio Heller
Andrea, quello che voglio dire è che, se vuoi generare un errore personale (un errore che non è un errore di PHP ma è un errore per te) devi in ogni caso lanciarlo (con trigger_error o attraverso un throw.
Ed è esattamente lo stesso fastidio di usare $this->dispatchEvent
[/supersaibal]

se lo vuoi chiamare fastidio ok, pero' gestire le eccezioni e' piu' portabile del tuo metodo, lo usi con classi dedicate Exception, usi sempre costrutto try catch, riadatti piu' facilmente lo script ... in fondo anche in ActionScript 2.0 le hanno aggiunte, ci sara' pure un motivo

Ho capito cosa intendi tu ma quello che ho detto io e' che il tuo e' solo un metodo di gestione errori come tanti altri ce ne sono e piu' "standard", io ho fatto solo un esempio scritto al volo per mostrare, magari non a te, un' alternativa

[supersaibal]Originariamente inviato da Fabio Heller
Non ho capito, quindi attraverso PDO, PHP5 supporta già SQLite 3?
[/supersaibal]

il file lo crea, la tabella pure, ho difficolta' in lettura records ma penso sia io il fagiano e che che sia gia' disponibile sqlite3 come lo era sqlite per PHP4 tramite PECL

[supersaibal]Originariamente inviato da Fabio Heller
Da quanto ho letto PDO sarà stabile e incluso di default (senza PECL) in PHP 5.1 , quindi stanno facendo grossi passi avanti davvero: una sola interfaccia per più database come in PERL [/supersaibal]

esatto e la cosa fantastica e' la gestione simile php5 e mysqli su mysql 4.1 , io l' ho implementata "a mano" su Sqlite 2 per php5 e non sapevo esistesse in PDO .... sbavevole

[supersaibal]Originariamente inviato da denadai2
io direi giusto per complicarsi la vita... [/supersaibal]

la gestione degli errori e' parte fondamentale di un applicazione, certo se vuoi metti @ davanti a tutto e li si che fai un applicativo serio


torna ad intasare l' host di la

[denadai2]

cmq ho capito solo ora.. interessante nn saprei applicarlo ma.. interessante

nn uso quasi mai la @ cmq vieni ad aiutarmi a buttare giu areaserver ti pregoo

[Fabio Heller]

[supersaibal]Originariamente inviato da andr3a
se lo vuoi chiamare fastidio ok, pero' gestire le eccezioni e' piu' portabile del tuo metodo, lo usi con classi dedicate Exception, usi sempre costrutto try catch, riadatti piu' facilmente lo script ... in fondo anche in ActionScript 2.0 le hanno aggiunte, ci sara' pure un motivo
[/supersaibal]

Infatti il metodo degli eventi è soprattutto un'alternativa alle eccezioni quando queste non ci sono: cioè la cosa più simile alle eccezioni che si possa tirare fuori in PHP4.
Ed è di gran lunga più comoda dei metodi PHP4 tradizionali.

Penso sia como anche in PHP5 quando l'evento con il quale vuoi interagire non è un errore, ma un'altra cosa

Es

$db->addEventListener('onFoundNoRows', $listener) ;
$db->query($select_query) ;


Ora il fatto che una query restituisca 0 righe non si può considerare un errore (e non va trattato come tale) ma potrebbe essere un evento.
Ogni volta che una query restituisce 0 righe posso decidere di agire in un certo modo e di stabilirlo una volta per tutte in un solo punto del codice.

Ovviamente è solo un esempio e il concetto si può applicare a altri tipi di "eventi"

[skidx]

[supersaibal]Originariamente inviato da Fabio Heller
Infatti il metodo degli eventi è soprattutto un'alternativa alle eccezioni quando queste non ci sono[/supersaibal]

Al contrario: usando il paradigma a eventi la gestione errori è solo la punta dell'iceberg delle funzioni che si possono sviluppare. Si possono gestire interazioni complesse tra oggetti anche in termini "positivi", senza limitarsi ai soli errori.
Le eccezioni invece sono limitate alla gestione di questi ultimi (le "eccezioni" appunto ).

Ho tirato su il thread per segnalare un PDF e un link:
http://www.php-tools.net/downloads/s...ent-Driven.pdf
http://developer.apple.com/documenta...Notifications/

Spero di aver fatto cosa gradita

[andr3a]

[supersaibal]Originariamente inviato da skidx
Le eccezioni invece sono limitate alla gestione di questi ultimi (le "eccezioni" appunto ).
[/supersaibal]

boh, secondo me una volta estesa la Exception con una classe tua le usi come ti pare ... anche come gestori eventi, non vedo alcun limite su una classe modellabile e customizzabile a proprio piacere, per ipotesi il metodo di Fabio potrebbe essere integrato a quello che ho scritto io senza troppi sforzi con la semplificazione per errori ed exceptions, appunto ... in piu' metti una __call , ad esempio , e ti fai anche l' event Handler ... cmq link utile

[Fabio Heller]

Utilissimo Skidx!
Specialmente il primo fornisce una panoramica sull'event based programming su WEB. Come nel caso degli eventi PEAR un po' mi dispiace (perchè speravo di aver tirato fuori qualcosa di nuovo per PHP ) , ma sicuramente dimostra che, ancora una volta, quando le funzionalità "esotiche" (tipiche di piattaforme "ricche" come Java e .NET) sono utili sul WEB, molte volte sono replicabili anche in PHP.


a questo proposito rilancio

Ispirandomi, in maniera casareccia, al .NET e per la prigrizia di non servirmi di framework complicati come PRADO quando programmo in PHP ormai utilizzo quasi sempre questa tecnica


Ogni volta che l'utente clicca sul bottone di un form o su un link invia al server (post o get) un'accoppiata oggetto-metodo.

Lato server uno script php fa da "front-controller", riceve l'accoppiata, include l'oggetto ed esegue il metodo.
Argomento del metodo è sempre e comunque l'array $_REQUEST

Insomma qualcosa del genere (semplifico per far capire cosa intendo)

Esegui Azione1

oppure

<input name="EVT['oggetto1.metodo1']" type="submit" value="Esegui azione1">

<input name="EVT['oggetto1.metodo2']" type="submit" value="Esegui azione2">

<input name="EVT['oggetto2.metodo1']" type="submit" value="Esegui azione3">

Ovviamente, nel caso dei bottoni, lo script lato server è in grado di andare a leggere il contenuto di EVT[...]
Tutto ciò senza essere costretto ad usare Javascript.

Personalmente ritengo che considerare la pagina HTML come un interfaccia da cui inviare comandi mi semplifichi di molto la programmazione lato server

[andr3a]

[supersaibal]Originariamente inviato da Fabio Heller
...
Argomento del metodo è sempre e comunque l'array $_REQUEST
[/supersaibal]

scusa Fabio, ma usando sempre il $_REQUEST non e' per certi versi come avere register global a on ? :master:

[Fabio Heller]

[supersaibal]Originariamente inviato da andr3a
scusa Fabio, ma usando sempre il $_REQUEST non e' per certi versi come avere register global a on ? :master: [/supersaibal]

No, perchè?
Come sai quello che c'è in $_REQUEST è la somma di $_GET + $_POST + $_COOKIE

se mi serve una variabile da $_COOKIE la prendo comunque in $_COOKIE, mentre anche se dovessi fare confusione tra $_GET e $_POST non accadrebbe nulla di pericoloso

[skidx]

[supersaibal]Originariamente inviato da andr3a
boh, secondo me una volta estesa la Exception con una classe tua le usi come ti pare ... [/supersaibal]

non solo sarebbe snaturare il concetto di eccezione, ma oltrettutto per far questo bisognerebbe includere tutto lo script in un'unico grosso blocco try{}, visto che a priori non sai che oggetto né a quale livello verrà sollevato un evento.

Io sono più per il concetto "Unix": fai una sola cosa e falla bene.

Quindi: le eccezioni fanno benissimo il loro lavoro, per intercettare appunto le eccezioni nelle sezioni critiche del codice. Gli eventi svolgono un ALTRO lavoro.

Fabio, la tua idea è senz'altro buona soprattutto perché mette un "ordine" nei possibili modi di implementare un'applicazione.

Io ho la mentalità (sbagliata) un po' 'fifona', per cui ho sempre paura, quando non padroneggio un metodo di lavoro, che sia limitante nel mio lavoro di codifica.
Il tuo metodo comunque mi piace molto, se hai altre informazioni/esempi o suggerimenti in merito, sono ben accetti.

[andr3a]

[supersaibal]Originariamente inviato da skidx
non solo sarebbe snaturare il concetto di eccezione, ma oltrettutto per far questo bisognerebbe includere tutto lo script in un'unico grosso blocco try{}, visto che a priori non sai che oggetto né a quale livello verrà sollevato un evento.
[/supersaibal]

per implementare intendevo fare tutto identico con la sola differenza di poter creare eccezioni .... ovvero come fa Fabio con in piu' le exceptions, qualora l' event handler riscontrasse problemi di manipolazione dinamica ...

la sola cosa e fatta bene sarebbe appunto la classe usabile singolarmente per le eccezzioni o in accoppiata ad un altra sola classe fatta bene per gli eventi


la mentalita' Unix e' si che e' ttto fatto bene preso singolarmente, ma e' anche tutto fatto bene per legare con il resto ... o no ?