[Zope-dev] IUnicodeEncodingConflictResolver moronosity

[Andreas Jung]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First, cool down for a moment.

Second, I discussed all those issues with my special friend in some
Launchpad ticket years ago (+ a huge amount of private discussions).
I can not recall all details but at the time of the integration of the
Zope 3 ZPT engine the unicode resolver approach was the best thinkable
solution for dealing all possible edgecase where encoding issues may pop
*for the sake of backwards compatibility* and with all possible
combinations where encodings have to be considered (including stuff like
the management_page_charset property). The implementation is
now working for years - so it can't be that bad. If you have a better
implementation you should be able to override the utility or to fix
the code directly.

I won't comment after years on the details below (check Launchpad for
the related ticket).

Andreas



Chris Withers wrote:
> Hi All,
> 
> It's been a a while since I had a good rant on a Zope list, but this
> really takes the biscuit.
> 
> Andreas, what on *earth* were you thinking with PreferredCharsetResolver?!
> 
> I like the idea of IUnicodeEncodingConflictResolver, but
> PreferredCharsetResolver is in the realms of totally batshit crazy.
> 
> Why? well, because what *on earth* have the character sets accepted by
> the user agent got to do with how strings are encoded in *my database*?!
> 
> Nevermind the logic holes of the following:
> 
> - reverting to management_page_charset *only* if there's no REQUEST
> (there's always a REQUEST, this is Zope 2, the world collapses if there
> isn't!)
> 
> - returning the original text if the bizarre dance fails, violating the
> contract of IUnicodeEncodingConflictResolver to *return unicode*
> 
> How about the *insane performance overhead* of doing two utility lookups
> *and* iterating over a load of encodings trying to find one that works
> for *every single string substituition* done by a ZPT?!
> 
> Why has no-one noticed this? Well, my guess is because when browsers are
> explicitly supplying headers, as quite a few do (IE and Safari excepted,
> who are legitimately going "we can handle anything you can throw at
> us"), this moronic piece of code happily loops through them all, and no
> doubt gets a hit on either utf-8 or latin-1, or, if you're really lucky,
> ascii.
> 
> To boot, when things go wrong, nobody suspects this miserable little
> turd because it's hides itself nicely by just returning the original
> text, leaving the bemused reader to wonder why some UA's fail and some
> succeed, pointing the finger in totally the wrong direction (hence
> Charlie's hacked up getPreferredCharsets and poor Vlad's desperate
> attempts).
> 
> Thankfully, I guess I can register an override that doesn't bark at the
> moon and froth at the mouth... Here, have an invoice for the hours of my
> life you've needlessly wasted...
> 
> Faaaaaaaaaaaaarq,
> 
> Chris ;-)
> 


- -- 
ZOPYX Limited           | zopyx group
Charlottenstr. 37/1     | The full-service network for Zope & Plone
D-72070 Tübingen        | Produce & Publish
www.zopyx.com           | www.produce-and-publish.com
- ------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJMmRMqAAoJEADcfz7u4AZjThgLvjIWRhiVWoV/0IG7qadEliG0
Dk1+v+hu3ocu0DURn9XK5nGrHkkR+cFIjYdyjArDfXTqoNXWPii90QbtypK7Lce8
PD2rPp+fnwyMSne9iz9s/LtYYrDO/gbxWx9robjyjGmvICthKZD/qZk3cM47SSzq
rhZLRV+r6GwVemn8sQEQ/y3gXKMgP7txz/Co1reWdWgrRH2HX4qpzvKHVLykXIrT
lx4D9X0UfxGO+64p7MCEOgg41W3EzNM3qIEGp4PUTTwjcp/Use+AP5kS+Q6vQEWV
n4c3RdaIX35EMNjVaunh0SMj+75rizMTarkGJ9e5lxekQLxqrveTiKqgGWtManD4
fjCSXpaobvy1Ym02CSLSLmSA4Y8ETTvdM87covKBvXHfaDyn5zxZaCmJ66L7Y+1i
OwnbtFIke4tLFGhsEQDcbSBQDMD6TNuA1h/SQJ5AXAT3kSBPPvhWS/C8tWvoEdft
dhzLEvXmpqMyA/4EgrMh6zP5fuGGkuM=
=WUsF
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20100921/c20e3603/attachment.vcf