On 8/18/06, Andrea Giammarchi <[EMAIL PROTECTED]> 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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
