[Python] mod_python ed il giusto handler

[Andrea Giammarchi]

Allora, raccolgo le palpebre per questa ultima email spero chiarificatrice.

Valentino Volonghi aka Dialtone ha scritto:
> Non e` una risposta a quello che ho scritto :). Tu dicevi che volevi 
> evitare il debug lato client il piu` possibile
esatto ... e sai perchè ? perchè non devo scrivere due volte il codice 
per quelle classi, è già pronto, mi preoccupo del resto, la classe la 
sviluppo per il server, qualche metodo che mi serve sul client lo esporto.
Non c'è alcuna rinuncia, visto che l'architettura è sul server.

I frameworks / toolkit noti del php che ha molte più varianti di quelle 
per Python (pensate quanto sono malato ... il fatto è che le ho viste 
quasi tutte e gran parte mi ha deluso per una serie di problemi non da 
poco) ed alcune permettono di usare funzioni php (chiamatele come 
volete) e non oggetti, dichiarate nel server ed esportate a mano, sul 
client, creando in automatico porzioni di codice per il client per 
sfruttare queste funzioni.
Questo concetto, lo fanno anche diverse vostre lib Python (tutte quelle 
che ho visto sfruttano JS da includere, o metodi per esportare funzioni 
, classi o oggetti), ovvero creano il JS utile per sfruttare via JS il 
fw, che poi voi scriviate quello che vi pare nel JS è stranormale, lo si 
fa con tutte le lib (mochkit e athena compresi ma "quelli li adorate 
tutto il resto è inutile") .
Solo alcuni, in PHP, esportano anche metodi di classi o classi ... e 
fanno a grandi linee quello che ho già fatto io tanti mesi fa con AJSHP, 
solo che io l'ho automatizzato.
Sviluppo con ajax da anni, con ajshp da tanti mesi e sono abituato a 
scrivere sul server, sfruttare quanto mi serve sul client, dedicarmi 
solo al resto del client pur ricordandomi sempre che ho quella classe 
con quel metodo presa dal server che fa quello per me (anche voi ? bene).
A differenza di tante altre librerie in PHP, AJSHP non aveva problemi 
con le sessioni, con le chiamate multiple (può capitare di fare chiamate 
incrociate, un intervallo on-line-users mentre si fa un login, per 
esempio), era velocissima sul server proprio perchè non usava JSON ed 
era nativamente compatibile con le variabili di PHP grazie alla 
serializzata.
Io sono abituato così, poi un guorno arrivo ad interessarmidi mod_python 
e mi sento dare dell'incompetente, deficente ... etc etc ... a ragà, e 
mica sono tutti uguali i linguaggi, n'attimo !!!
Mi ritrovo a non avere niente se non una sfilza di "bellissimi" FW / 
Toolkit già fatti, ma ho avuto esperienze deludenti con quelli PHP più 
noti (il paragone non regge ? non ho tempo di verificare).
ACE era già stato scritto perchè mi semplifica ulteriormente il tutto 
aggiungendo maggior sicurezza e compatibilità nativa con multibytes di 
php serializzato, ACE di fatto è "il figlio di AJSHP", colma le cose che 
non andavano, è stato riscritto nei punti critici e vorrebbe essere 
portato anche su C# o mod_python perchè IO, non mi sento più di usare 
solo il php (ma nemmeno di rinuciarci) visto che mi sta facendo sempre 
più schifo e se mi capitano progetti con C# o mod_python (più facile il 
primo) devo essere pronto a portarmi dietro tutte le mie belle lib che 
con gli anni mi sono fatto per fare aree admin o altro ancora.

Non nego di non essermi preoccupato tanto della fattibilità della cosa 
per altro abbastanza banale in PHP (davo per scontato che i potenti 
rivali potessero fare altrettanto bene ed altrettnto semplicemente), ma 
vi assicuro che per me è un modo performante, semplice e veloce di 
lavorare (per me ... sarà abitudine) quindi vorrei assolutamente 
riuscire a fare questo benedetto porting per altre tecnologie, così 
almeno io, non mi devo trapanare le palle a riscrivere tutto per 
riadattare il mio js a quella o quell'altra libreria strafica che però 
usa metodi tutti suoi.
Non uso Dojo, non uso prototype, tutto quello di JS che c'è già di noto 
non mi garba per una serie di motivi per me validi, scrivo le mie lib JS 
leggere, ottimizzate, i miei components, fine, la pace dei sensi per 
quel che mi riguarda, visto che con gli anni le ho fatte sempre meglio 
(almeno in JS) ed alcune sono veramente testate o almeno non mi hanno 
mai dato problemi con nessun browser.

Ecco perchè un idiota piaccaparo arriva in ml python e comincia a 
delirare, ai vostri occhi, per una libreria inutile, spreco di tempo e 
tutto quello che volete .... ecco perchè per continuare a stare a galla 
in questo settore devo poter fare cose il più velocemente possibile 
senza avere limiti tecnologici (server .NET ??? ... ok, server PHP ??? 
... ok, serve mod_python ? ... boh, ci provo, ma almeno il client so che 
è OK) ... ecco perchè ACE nasce anche semplice, da usare non da fare, 
diverso da altri, ovvio, ma potenzialmente adatto ai molti che 
potrebbero ritrovarsi nella mia situazione (almeno un paio ne conosco).

Ora rivedrò le mie convinzioni su cosa è veramente OO e cosa intendo io 
per scrivere OO o sfruttare la stessa OO su più linguaggi, abituato a 
comunità di livello tecnico spesso discutibilissimo.

Rinnovo la buona notte, stò cotto e fuso.

Saluti,
    Andrea Giammarchi