[PIPPE MENTALI] gestione degli eventi in PHP

[andr3a]

[supersaibal]Originariamente inviato da skidx
Ben venga l'uso di tecnologie lato client per arricchire e facilitare il compito all'utente, ma è sbagliatissimo costruirci sopra il cuore di un'applicazione o di un framework.

A meno che tu non sia Google e stia sviluppando Gmail, certo, ma qua voliamo un pelino più bassi, e si ragiona su sistemi più versatili [/supersaibal]

ma che risposta e' ???

1 - era solo un' ipotesi
2 - se crei il JS in modo dinamico tale che la struttura server venga riprodotta per situazioni al fine di snellire l' eventHandler server-side, con i soliti , normali e dovuti controlli, potresti gestire in modo piu' snello le chiamate al server, se era questo il problema
3 - non posto piu' in questo 3D , mi state rigirando e male ogni mio post ... quindi a voi la parola

[Fabio Heller]

P.s.
In ogni caso di tutti i framework PHP che ci sono in giro (quelli che ho visto) non ne ho ancora trovato uno che su un server sotto pressione non possa avere problemi di performance dovute all'assenza di e persistenza tipica di PHP (file di configurazione enormi, decine di inclusioni etc.etc.)
Il fatto è che in questi casi bisogna ricorrere a tecniche di caching e compilazione del bytecode.
E infatti questi framework, grazie a queste accortezze, continuano ad essere usati con successo anche su siti molto molto frequentati. Un nome per tutti: TYPO3

[skidx]

[supersaibal]Originariamente inviato da andr3a
ma che risposta e' ???

1 - era solo un' ipotesi
2 - se crei il JS in modo dinamico tale che la struttura server venga riprodotta per situazioni al fine di snellire l' eventHandler server-side, con i soliti , normali e dovuti controlli, potresti gestire in modo piu' snello le chiamate al server, se era questo il problema
3 - non posto piu' in questo 3D , mi state rigirando e male ogni mio post ... quindi a voi la parola

[/supersaibal]

andrea, ma hai le tue cose?
Era una risposta normalissima e tranquilla.
Tu hai detto: perchè non basarsi su javascript?
Io ti ho risposto: perché l'applicazione non è versatile, se la leghi a filo doppio con una tecnologia client-side.
Nessuna polemica e nessuna competizione, davvero.


Fabio, ok, io supponevo ti basassi su una validazione di tipo "white-list" anche per gli oggetti da includere, invece mi pare di aver capito che tu demandi questa validazione al web server (se il file non c'è non lo puoi includere ) e usi un'approccio white-list per i metodi direttamente negli oggetti, quindi "distribuito".

Sì, mi piace già di più, grazie.

L'unico vincolo è che la classe da istanziare deve avere lo stesso nome dello script che la contiene, mi pare, o sbaglio?

[andr3a]

[supersaibal]Originariamente inviato da skidx
andrea, ma hai le tue cose?
[/supersaibal]

m'hanno scoperto

[supersaibal]Originariamente inviato da skidx
Era una risposta normalissima e tranquilla.
[/supersaibal]

se lo dici tu ... e' che per una volta che non volevo fare lo sborone m'hai dato del googlelaro


pero' JS quando si tratta di web non e' una tecnologia qualunque , c'e' e penso ci sara' sempre

vero che non sarebbe molto portabile, vero anche che come dice Fabio alla fine con pseudocompilati il tutto dovrebbe reggere senza problemi, vi lascio lostesso alle vostre conslusioni

[Fabio Heller]

[supersaibal]Originariamente inviato da skidx
L'unico vincolo è che la classe da istanziare deve avere lo stesso nome dello script che la contiene, mi pare, o sbaglio? [/supersaibal]

Sì è così, ma è una prassi consolidata nei linguaggi object oriented:
1 classe -> 1 file con lo stesso nome

La white list è necessaria per quanto riguarda i metodi degli oggetti in PHP4, in teoria in PHP5 basterebbe dichiarare privati i metodi che non possono essere chiamati e gestire l'eventuale errore

A dire il vero comunque si potrebbe fare una cosa molto semplificata anche senza OOP (sempre senza switch)

Includere dei file che contengono un array di azioni (grazie alle "funzioni variabili" di PHP)

Es.
$actions = array(
'azione1'=> 'funzione1',
'azione2' => 'funzione2'
) ;

//ecco la chiamata
$actions[$_REQUEST['azione']]() ;

[skidx]

[supersaibal]Originariamente inviato da andr3a
se lo dici tu ... e' che per una volta che non volevo fare lo sborone m'hai dato del googlelaro [/supersaibal]

nu, mi hai frainteso, ho citato l'esempio di Google perché GMail è forse la più nota applicazione web (tra quelle degne di nota ) a essere basata totalmente su javascript.

Loro possono perché sono committenti e realizzatori della applicazione stessa, diverso è il caso di una applicazione utilizzabile e modificabile da altri.

Fabio, a me interessava per PHP5, e infatti avevo già immaginato una struttura con metodi pubblici, privati e il metodo magico __call() per gestire gli errori di eventuali metodi inesistenti. Dovrebbe fungere, no?

[Gianni_T]

un po' di filosofia:
se non ho capito male, si sta discutendo su come mettere in piedi una applicazione PHP "event driven".
E' evidente che questo tipo di programmazione richieda un dispatcher e quindi centralizzi la gestione degli eventi, cosa che potrebbe creare un collo di bottiglia.
Ma mi chiedo, questo approccio è indicato per il web? Per una applicazione tradizionale che dispone di una GUI questo approccio è obbligatorio, si aspetta che l'utente clicchi da qualche parte e si gestisce la notifica che il SO invia. In questo contesto il SO non sa che fare, demanda tutto all'applicazione che sta li ad ascoltare.
In ambiente web invece non c'è l'applicazione ad ascoltare, c'è il server web che sa perfettamente cosa fare a fronte di una richiesta ovvero sa quale file caricare. Voler ricreare l'approccio "event driven" in un contesto web richiede infatti un notevole sforzo perché il web (le reti, i protocolli, i server) non sono fatti così.
Chi riscuote i maggiori benefici da questo approccio, l'utente o lo sviluppatore? Non credo che gli utenti si accorgeranno mai della differenza. Quindi dovremmo beneficiarne noi? A guardare gli sforzi necessari e gli effetti collaterali sembra proprio di no.

Ovviamente questo discorso non può valere per tutte le applicazioni. Ma forse è proprio la voglia di trovare un approccio valido alla realizzazione di diverse applicazioni, la voglia di costruire un framework, che porta alla realizzazione di questo modello "event driven".
Forse anche perché così consolidato nell'esperienza degli sviluppatori che non si riesce più a capire se il gioco valga la candela.

Ho bevuto troppo a tavola ?!?!?

[Fabio Heller]

[supersaibal]Originariamente inviato da skidx
Fabio, a me interessava per PHP5, e infatti avevo già immaginato una struttura con metodi pubblici, privati e il metodo magico __call() per gestire gli errori di eventuali metodi inesistenti. Dovrebbe fungere, no? [/supersaibal]

sì è una buona idea, ma non so se sia bene "sprecare" __call (che può essere sempre utile) per gestire gli errori,

Non ricordo se la chiamata, non gestita, di un metodo inesistente genera un errore fatale o solo un warning, nel secondo caso forse basterebbe attivare il tracking degli errori e alla chiamata

@$oggetto->{$metodo}() ;

verificare se $php_errormsg è vuota

[Fabio Heller]

[supersaibal]Originariamente inviato da Gianni_T
Ho bevuto troppo a tavola ?!?!? [/supersaibal]

No, non direi

Il vantaggio, per come come la vedo io, è per lo sviluppatore. Ovviamente per l'utente finale non farà differenza.
L'utente finale di solito si accorge della grafica, non del funzionamento di ciò che sta dietro all'interfaccia grafica.

Infatti i vantaggi di "complicarsi la vita" con frameworks o tecniche più o meno complicate secondo me sono tutti dello sviluppatore: sviluppo e debug più rapido, tutto qui.

Ovviamente questo approccio richiede che si debba perdere del tempo, inizialmente, a imparare un metodo meno immediato.
Ci si deve documentare, sì può sbagliare, si può perdere del tempo ma alla fine chi segue questo approccio trova il metodo che gli è più congeniale.
L'alternativa è fare le cose al solito modo: tanta routine e poco divertimento.

[Gianni_T]

[supersaibal]Originariamente inviato da Fabio Heller
Infatti i vantaggi di "complicarsi la vita" con frameworks o tecniche più o meno complicate sono tutti dello sviluppatore: sviluppo e debug più rapido, tutto qui.[/supersaibal]

Sono daccordo sull'uso di approcci ben strutturati, ma non so se quello ad eventi sia valido in questo contesto, almeno in linea generale. Credo che tecniche più snelle e meno "one script for all" permettano altrettanta velocità di sviluppo e debug.