[Python] mod_python ed il giusto handler

[Valentino Volonghi aka Dialtone]

On Fri, 18 Aug 2006 22:06:18 +0200, Andrea Giammarchi <andrea a 3site.it> wrote:
>ovvio, in python però puoi anche non farlo e gestire runtime classi JS ergo 
>non scrivi sempre e comunque il codice 2 volte.

Te lo ripeto: e` meglio evitare questa boiata.

>l'invio e la ricezione di oggetti, ribadisco, è un di più, non l'essenza 
>della lib che fa tutto quello che fate voi oggi, ma da anche questa 
>possibilità che a voi non interessa per alcun motivo (a me si)

Allora... E` evidente che non ne sai molto neanche di OO perche` continui a parlarne. Non stai facendo nulla di 'OO' se invii il nome di una classe e il suo stato. Stai solo inviando una stringa e altre stringhe.

Per essere 'OO' (se mai questo fosse davvero la soluzione a tutto) serve che si sia anche l'ereditarieta` oltre che organizzare stato e metodi che agiscono su quello stato nella stessa struttura sintattica.

In quello che fai tu non c'e` _NULLA_ di OO, c'e` solo l'uso improprio di oggetti in javascript per evitare di passare un nome come parametro di una funzione, ben poco per dire di aver rivoluzionato e veramente compreso cosa significa OO.

>approccio a specchio, puoi gestie oggetti client e server allo stesso modo 
>sul client come sul server

Ascolta... Qua siamo piu` o meno tutti sviluppatori. Mi servono usecase, io non mi fido dei commerciali delle aziende mi serve capire il problema che risolve e perche` e` meglio risolverlo cosi`. Quanto mi hai scritto sopra ha ben poco di tecnico perche` l'approcio a specchio non ho idea di cosa sia e gestire oggetti client e server allo stesso modo e` assolutamente impossibile visto che il client e` javascript e il server e` python.

>troppo ...

Sticazzi che e` troppo e` un client IRC via web completo.

>>Il metodo lo devi scrivere comunque in javascript quindi questo non c'entra 
>>niente.
>scrivi una classe (funzione) fine, non devi poi rifare niente, ti ritrovi 
>l'istanza malipolabile, inviabile, etc etc

Io non lo capisco... Mi arrendo. Che vantaggi ci sono?

>>Lavori il doppio perche` il tuo modello e` enormemente piu` complesso da 
>>gestire.
>quello mio si, quello finale a livello di utilizzo non ha nulla di 
>complesso, è a prova di niubbi, sai definire un dict statico di una classe ? 
>(methodTable) sai fare interazioni avanzate in ajax con JS sapendo poco 
>anche di JS.

Non so cosa sia un'interazione avanzata.

>invii uno stato che ricrea l'oggetto ergo invii oggetti e non devi fare 

Invio uno stato e basta. Lo stato e` stato non ricrea.

>>E` tremendo. Quindi io posso accedere a tutti gli oggetti che voglio lato
>>client facendo quello che desidero attraverso quegli oggetti?
>ma non diciamo cavolate, grazie

Se crei classi a runtime direi che ho ragione io non tu.

>>Che poi e` molto
>>poi semplice fare una cosa tipo:
>>
>>callRemote("sayHello").addCallback(function(str) {alert(str)})
>la callback semplifica ? callRemote è una sola funzione ?
>devo farne una per ogni tipo di callRemote ??? .... e quando ti passa a te ?

callRemote e` una funzione e ne esiste una e basta.

>>oppure
>>
>>function progress(perc) {alert(perc)}
>perfetto
>
>pippo.methodName.progress = progress;
>che assegni a tutti i metodi che ti pare ... il progress non è una chiamata 
>al server eh ... non facciamo confusione, il progress è lo stato di 
>ricezione del client della stringa sul server.

E chi ha detto che la progress e` una chiama al server? Io ho detto che la chiama il server non il contrario.

>Per un login un progress non servirà mai ad una fava, per un portale di 
>informazioni magari si .... altra cosa che io faccio da tempo e che altre 
>lib non hanno (almeno in php e mi sembra nemmeno in .NET, non so in Python)

Ti svelo un segretone:
Io uso quello che ora chiamano ajax e quello che ora chiamano COMET da 2 anni prima che diventassero famosi con quei nomi.
Con il framework che sviluppo ci hanno scritto:
http://numbler.com/
http://snipshot.com/

Uno spreadsheet e un editor di fotografie dici che sono abbastanza complessi da poter essere definiti 'interazioni avanzate ajax' qualsiasi cosa questo significhi?

>>lasciando al server il compito di chiamare perc quando necessario senza 
>>scomodare
>>il client.
>ah certo, tu scomodi il server ...

Non si tratta di scomodare il server. Si tratta di far fare a ognuno il suo lavoro.

>>charcode non sara` mai piu` di 256 a meno che s non sia unicode perche` per 
>>ottenere
>>piu` di 256 ti serve un carattere multibyte che non otterrai mai senza 
>>usare unicode.
>infatti lavora in multibyte ...

Cosa significa? che s e` unicode? Altrimenti non stai lavorando in multibyte perche` s[indice] se s e` una stringa di byte non ritorna il carattere ma il byte e quindi non stai lavorando in multibyte.

>credo ti sfugga il significato delle mie parole tra " e " che mi evitano, 
>presumendo di avere a che fare non con un robot, di scrivere pile di 
>caratteri ... riassumendo in modo semplice

Ma tu lo capisci che non basta mettere "foo" per fare in modo che io capisca cosa significa il fatto che le hai messe tra virgolette? Oppure pensi che dato che scriviamo le stesse parole entrambi attribuiamo ad esse lo stesso significato all'interno di una frase?

>bene, quindi il web lavora tutto su u ? devo informarmi a riguardo

Il web lavora con stringhe che hanno un encoding e tu devi decodificarle e trattarle solo dopo averle decodificate. Cosi` si fa e chi non lo fa sbaglia. (sia esso python, java, C#, PHP, perl, ruby, brainfuck, d, c, C++, haskell, smalltalk, common lisp, scheme, erlang, boo, vb.net e chi piu` ne ha piu` ne metta).

>anche la serialize è già scritta per tanti linguaggi ... ma se per partito 
>preso devi rinunciare a tutto quello che non è JSON io non posso farci 
>niente

Ma cosa c'e` di difficile nel rispondere a un quesito che riguarda i vantaggi della tua soluzione? Posto che 'e` piu` OO' non e` vero.

>quello che se su google scrivi python php serialize è tra i primi col suo 
>package che è tra i più noti (l'unico ? io ho visto solo quello ...)

E` indubbio che non l'ho mai sentito nominare :).
I suoi utilizzatori pero` stanno utilizzando questa implementazione della serialize per migrare via da PHP (e poi la abbandoneranno visto che non la usano per comunicare con il browser client). Tra l'altro l'ultimo delle success stories stara` probabilmente migrando al mio framework.

>io non voglio alcuna pacca, a me quella versione non andava bene per 
>mancanze per me irritanti, riscritta, messo tra i credits, fine, pacce di 
>cosa che c'ho già messo un cratere ?

Pacche non ne vuoi, critiche neanche. Quindi siamo un servizio di assistenza gratuito e basta.

>piuttosto parlatemi di come risolvere il cratere, grazie

Appunto.

>json in C mi sembra ci sia, json in PHP l'hanno fatto anche in C come modulo 
>per evitare che "i server saltassero per aria" ma non è presente da nessuna 
>parte, json in python non so quanto sia performante, ma se ha i tempi della 
>pear, sviluppate su applicativi che con tanti dati e due o tre utenti in più 
>fanno sudare qualunque server ...

Non hai capito quello che ho scritto... Ma qui davvero non e` un problema, non cambia poi molto.

>>Nasconde semplicemente il procedimento di serializzazione di oggetti 
>>arbitrari
>>che non va nascosto per varie ragioni che spieghero` solo se avrai voglia
>>di discutere invece che prenderla sul personale.
>parliamone

No perche` da quanto ho visto sopra la lista non e` degna di muovere critiche al tuo progetto perche` sono fatti tuoi. noi dobbiamo aiutarti a risolvere il tuo problema, non discuterne. E se vuoi una consulenza da me devi pagare per averla, come fanno i miei clienti.

Il problema principale e` il poco controllo che lasci al tuo utilizzatore e questo e` male.

>>Gli encoding hai ammesso di non conoscerli perche` con php non ti sei mai 
>>posto
>>il problema... Ora fai l'ironico a riguardo?
>e che mi devo mettere a piangere ?

Il bel tacer non fu mai scritto.