Valentino Volonghi aka Dialtone ha scritto:
E questo come e` possibile? Puoi inviare solo ascii?
utf8_encode ... utf8_decode
Inoltre se il tuo sogno e` tenere aggiornate le istanzi degli
oggetti tra server e client vivrai una vita grama e ricca di
spiacevoli sorprese.
soprese ancora niente, di sogno ben poco visto che lo faccio da tempo
Embe`? L'object system di javascript e` comunque diverso da quello di
python e
comunque devi riscrivere la classe sia in python che in javascript.
ovvio, in python però puoi anche non farlo e gestire runtime classi JS
ergo non scrivi sempre e comunque il codice 2 volte.
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)
A parte che l'approcio completamente OO non significa nulla. Ma non
vedo come
questo modo di serializzare de-serializzare oggetti possa far cambiare
l'approcio.
approccio a specchio, puoi gestie oggetti client e server allo stesso
modo sul client come sul server
Si. Faccio un esempio del codice javascript lato client su cui lavoro
abitualmente visto che probabilmente quello di cui parlo e` piu`
complesso di
quello che sembra: ....
troppo ...
Io uso JSON e mi sembra di usare un approcio a oggetti piuttosto
spinto lato
client. Giuro inoltre che potrei mostrarti una tonnellata di
javascript molto
piu` complesso di questo che utilizza ancora JSON.
ne sono convinto, JSON è eccezionale, in PHP JSON è un ammazza risorse
per via della lentezza orribile della conversione, PHP lo uso tuttora,
non userei mai ne farei mai una libreria ajax per php con JSON di mezzo
se non tramite il compilato che non è mai presente nei servers virtuali
e non
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
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 puoi inviare metodi con la serializzazione ma solo lo stato quindi
i metodi
devi comunque scriverli per cui non mischiare troppi argomenti.
invii uno stato che ricrea l'oggetto ergo invii oggetti e non devi fare
altro per usarli come tali
Come? E questo cosa ha a che fare col polimorfismo?
il polimorfismo non c'entrava niente , la frase era senza senso e commentata
Cosa c'entra? Non puoi trasportare i metodi. Devi scriverli i metodi.
bene
Permettimi ma non posso che dissentire, di semplice il modello non ha
nulla.
modello di cosa ?
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
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 ?
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.
Content-Length: 100Kb
il progress restituisce in automatico a readyState 3 la lenght della
stringa / getHeader("Content.Length"), non fa nulla di asincrono via
http, sempicemente da un riscontro quando serve.
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)
lasciando al server il compito di chiamare perc quando necessario
senza scomodare
il client.
ah certo, tu scomodi il server ...
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 ...
Ecco cosa tocca fare in JS come in Python (almeno credo sia così,
illuminatemi altrimenti) per ritrovare la len "fasulla" del PHP
Non c'e` nessuna len fasulla.
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
Assolutamente sbagliato e questo perche` non conosci gli encoding.
bravo
Ma il problema non lo risolverete ancora :).
lo so bene, lo sanno tutti, il background del php è sempre più incazzato
Ora pero` sei obbligato a portelo perche` in python questo problema
non e`
nascosto goffamente dal linguaggio ma ti viene sbattuto in faccia
facilmente.
bene, quindi il web lavora tutto su u ? devo informarmi a riguardo
Ma esiste gia` JSON, chissenefrega di una libreria usata in php perhe`
in php
JSON e` lento come la fame?
non condivido
Esiste gia` JSON, negli altri linguaggi dubito verrai accolto molto
differentemente
...
Se vuoi scrivere la tua libreria in python perche` serve al tuo
progetto nessuno
te lo impedisce ma e` difficile trovarne l'utilita` quando c'e` gia`
JSON che
funziona ed e` _gia`_ implementato in tanti linguaggi e la tua
libreria non
porta vantaggi di alcun genere per questo scopo.
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
Non mi spiacerebbe ma l'ultima volta che l'ho fatto il risultato e` stato
disastroso per cui prima mi firmi un documento che ti impedira` di
farmi causa
se la mia reazione sara` vigorosa, poi guardo il tuo sorgente.
ok
E chi e` il tizio?
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 ...)
Si. Pero` a me piace questo modo di comprendere l'open source dove non
esiste
discussione, se io ho un'idea e` giusta per forza perche` e` un'altra
idea, non
c'e` la possibilita` che sia sbagliata o che meriti una discussione in
cui
l'autore si trova a difendere le sue scelte progettuali. Semplicemente va
accettata e ci si riempie tutti di pacche sulle spalle perche` siamo
stati
bravi a creare l'ennesima variante di una libreria che esiste gia`.
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 ?
piuttosto parlatemi di come risolvere il cratere, grazie
Ma tu puoi scriverla come ti pare, te lo sto impedendo in qualche
modo? Magari
ti sfugge che stiamo discutendo di una tua libreria e riguardo alle
tue scelte
di inventare un nuovo formato di serializzazione che non aggiunge nulla a
JSON
ma non è inventato ... è questo che tutti state dicendo: perchè se c'è
già JSON .... ma cristoforo, c'era già anche la serialize, da anni per
tanti lignuaggi quasi quanti quelli per json ...
(non e` piu` semplice da parsare, non e` piu` veloce in Python se sia
il tuo che l'altro li si implementa in Pyrex [ma se nessuno ha
implementato
json in C/pyrex/boost/altro significa che non e` un problema per
nessuno]).
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 ...
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
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 ?
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
