[Python] mod_python ed il giusto handler

[Lawrence Oluyede]

On 8/18/06, Andrea Giammarchi <andrea a 3site.it> wrote:
> Lawrence Oluyede ha scritto:
> > Mi scrivi 5 righe della parte Python di gestione della roba JS con la
> > tua libreria?
> ti posto in fondo tutta la libreria .. che è ancora alpha e non è
> completa, ha diversi buchi, ma tutto sommato comincia a funzionare

Veramente io volevo un esempio di come si usa, non di come è scritta.
Comunque guardo.

def in_list(value, values):
   result = False
   for i in range(0, len(values)):
       if value == values[i]:
           result = True
           break
   return result

Si fa in una linea di python: "value in values" ritorna True o False.
Scusa la battuta ma parli di performance e scrivi cose come questa?
:-) Continuo:

getMethods() è piena di bad practices. Non usare has_key ma usa in
semplicemente. Poi basta isinstance() senza scomodare il modulo types
per vedere se qualcosa è di un certo tipo.
Il resto è tutto più o meno uguale. parseType con un dizionario la fai
in 3 righe ed è più facilmente manutenibile. Non te la prendere, ma se
studiassi un attimino di più Python magari faresti una lib
"performante". Sto ancora cercando di capire come quella tua lib
comunichi con JS.


> esporti classi che hanno metodi utili per il JS
> da JS usi queste classi, le istanzi, sfrutti gli oggetti già definiti
> dalla lib e per ogni oggetto hai già i metodi e per ogni metodo i tre
> metodi call, result, progress, puoi usarli tutti o nessuno
> Questa è la parte che interessa il primo invio poi questi oggetti, visto
> che hai esportato delle classi presenti con il methodTable, puoi usarli
> sul client o sul server perchè sono già presenti, il caso di oggetti
> non presenti e creati runtime è molto particolare e sono un pò stanco
> per spiegarlo bene.

No problem, orma mi rassegno. Voglio vedere un esempio, anche non
funzionante. Insomma... fammi una demo tipo:

a = classe1
b = classe2
c = fai qualcosa con a e b

Tanto per capire come si usa.

> > E' troppo perchè sono varie funzioni.
> appunto, io vorrei avere tutto disponibile subito

Non hai capito. Sono varie funzioni perchè ogni funzione gestisce un
evento separato. Tipo il connect al server, il quit, ecc ecc. Ste cose
le avresti anche con la tua lib eh

> ho già risposto a questa domanda, scrivo una lib che non è per l'uno o
> per l'altro, ma che per avere senso a livello di portabilità del client
> deve basarsi o su JSON o su PHP_Serializer, io ho scelto la seconda per
> rispetto del predominante nel web, PHP

Ok allora lasciami dire che a me pare una scelta sbagliata.

> > Interazione avanzate in AJAX?
> si, se AHAH è l' abc , con altre lib puoi fare interazioni più
> complesse, quindi più avanzate

Riformulo la domanda: che tipo di interazioni avanzate vuoi fare con AJAX?

> > Che vuol dire tipo di callRemote? La callRemot chiama una funzione e
> > piglia il valore di ritorno. Che c'è da riscrivere?
> niente, avevo capito male ... però questo non è un approccio procedurale ?
> io preferirei
> myClassVar.sayHello.call();

Eh si sicuramente sayHello.call() non è un approccio procedurale.
Vediamo di chiarirci:

- procedurale = chiamo una procedura. *ESATTAMENTE* la stessa cosa che
stai facendo tu.
- il tuo approccio è bloccante quindi se devi magicamente trasferire
mega byte di dati come dicevi la tua fantastica app si blocca.
callRemote() perlomeno è asincrono, come tutto in Nevow

> e nel frattempo hai anche un'istanza di classe da gestire come vuoi

Cosa fondamentale. Scusa sto diventando sarcastico.

> molto meno, per il semplice fatto che non ci sono caratteri da
> modificare, solo length da sfruttare.

Mi sa che non hai capito la mia domanda. Vedo di semplificare. Se
centomila server PHP nel mondo non installano JSON per PHP scritta in
C, credi davvero che installeranno la tua libreria?

> Il problema della length per UTF-8, come ho detto, è pià per portabilità
> della classe PHP_Serializer che altro, perchè trattando stringhe come
> text (numero dei caratteri), non è necessario usare
> UTF-8 con altri linguaggi diversi dal PHP, quindi è molto rapida.

Non ho capito NULLA di quelle quattro righe :-(
Non puoi basare la tua lib sperando di avere in ingresso sempre e solo
UTF-8 perchè UTF8 non è l'unico. Rispondo questo perchè non ho ben
capito il resto.

> > La tua lib in pyrex sarà ancora meno portabile sui server che non
> > preinstallano le librerie JSON in PHP performanti, vero?
> come sopra

Come sopra cosa? Son 3 post che cerco di farti notare che è meno
vendibile di quella JSON

> Devo ancora lavorarci sopra ... anche e soprattutto per l'import
> dinamico (ogni consiglio è bene accetto)

import dinamico? Ossignore :-)

Se vuoi ti dico qual è il meccanismo in Python per fare l'import
dinamico e quale modulo può farlo ma te lo lascio trovare da solo cosi
non mi sento responsabile per eventuali danni :-)

-- 
Lawrence
http://www.oluyede.org/blog