Or en ASP classique, Response.Write("hého €") marche très bien.
Et, en build 202 avec Python 2.2 je n'avais pas ce problème non plus
Vu que j'ai deja une grosse appli en prod qui ne spécifie pas le 'u'
pour encoder les chaines, y a t il un moyen de revenir au comportement
antérieur ou de overrider Response.Write ?
J'essaie de créer une fonction custom que j'affecte à Response.Write :
class MyResponse(object): @classmethod def Write(self,instr): Response.Write(unicode(instr))
Puis, remplacer tous les: Response.Write(... par: MyResponse.Write(...
-- @-salutations -- Michel Claveau
JB
Méta-MCI (MVP) a écrit :
Bonsoir !
Et comme ça :
class MyResponse(object): @classmethod def Write(self,instr): Response.Write(unicode(instr))
Puis, remplacer tous les: Response.Write(... par: MyResponse.Write(...
"@classmethod" permet de pouvoir appeler directement MyResponse.Write ?
Justement je voulais éviter d'avoir a tout ré-ecrire le code qui est historiquement 'php-style' donc lourd a faire évoluer.
voici une solution d'override adaptée d'une proposition de Mark Hammond, en attendant de voir d'ou ce changement d'encodage vient dans son code ou dans windows... :
<%@Language="Python"%> <% def my_write(v): if not v: return if isinstance(v, bool) or isinstance(v, long) or isinstance(v, int): Response.__dict__['_real_write'](str(v)) return try: v = v.decode("utf-8") except UnicodeDecodeError: # au cas ou chaine passée deja en unicode pass
je n'ai plus qu'a mettre ca dans mon include principal et ca roule....
vive django :p
ju.
Méta-MCI (MVP) a écrit :
Bonsoir !
Et comme ça :
class MyResponse(object):
@classmethod
def Write(self,instr):
Response.Write(unicode(instr))
Puis, remplacer tous les:
Response.Write(...
par:
MyResponse.Write(...
"@classmethod" permet de pouvoir appeler directement MyResponse.Write ?
Justement je voulais éviter d'avoir a tout ré-ecrire le code qui est
historiquement 'php-style' donc lourd a faire évoluer.
voici une solution d'override adaptée d'une proposition de Mark Hammond,
en attendant de voir d'ou ce changement d'encodage vient dans son code
ou dans windows... :
<%@Language="Python"%>
<%
def my_write(v):
if not v: return
if isinstance(v, bool) or isinstance(v, long) or isinstance(v, int):
Response.__dict__['_real_write'](str(v))
return
try:
v = v.decode("utf-8")
except UnicodeDecodeError:
# au cas ou chaine passée deja en unicode
pass
class MyResponse(object): @classmethod def Write(self,instr): Response.Write(unicode(instr))
Puis, remplacer tous les: Response.Write(... par: MyResponse.Write(...
"@classmethod" permet de pouvoir appeler directement MyResponse.Write ?
Justement je voulais éviter d'avoir a tout ré-ecrire le code qui est historiquement 'php-style' donc lourd a faire évoluer.
voici une solution d'override adaptée d'une proposition de Mark Hammond, en attendant de voir d'ou ce changement d'encodage vient dans son code ou dans windows... :
<%@Language="Python"%> <% def my_write(v): if not v: return if isinstance(v, bool) or isinstance(v, long) or isinstance(v, int): Response.__dict__['_real_write'](str(v)) return try: v = v.decode("utf-8") except UnicodeDecodeError: # au cas ou chaine passée deja en unicode pass
je n'ai plus qu'a mettre ca dans mon include principal et ca roule....
vive django :p
ju.
Méta-MCI \(MVP\)
Bonsoir !
OK, ça peut marcher. Mais, perso, je n'aime pas trop jouer avec les homonymes de fonctions/objets. C'est une source de confusion dans mon esprit étroit, que je préfère éviter.
-- @-salutations -- Michel Claveau
Bonsoir !
OK, ça peut marcher.
Mais, perso, je n'aime pas trop jouer avec les homonymes de
fonctions/objets. C'est une source de confusion dans mon esprit étroit,
que je préfère éviter.
OK, ça peut marcher. Mais, perso, je n'aime pas trop jouer avec les homonymes de fonctions/objets. C'est une source de confusion dans mon esprit étroit, que je préfère éviter.
