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).


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

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


<<attachment: lists.vcf>>

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to