The way WebOb deals with this is by allowing users to supply a "default_charset" attribute on requests (or during request construction). It'd probably be enough to allow people to do the same for Zope requests (maybe as a zope2.ini parameter); when it's non-None, use that as the charset to decode to unicode using. If it *is* None, behave as it always has.
- C Hanno Schlichting wrote: > Hi. > > Got a brainstorming question for the repoze.zope2 folks. > > Currently repoze.zope2 reuses the Zope2 ZPublisher request object pretty > much directly. This is nice for full backwards compatibility, which has > been a primary concern during its initial development. > > At some point in the Zope2 or at least Plone evolution we need to switch > the request to move from passing on encoded strings to doing the Unicode > conversion of at least form data. > > I think there is no graceful way of doing this. It's a binary choice of > either doing it or not. At least for Plone4 which is using repoze.zope2 > we have an increasing number of cases where we use Unicode instead of > encoded strings, especially when using Zope3 technology like > zope.formlib or z3c.form. > > Does anyone know of any good reason why we shouldn't switch over the > request object to something more modern and using Unicode? > > It's a backwards incompatible change, but one that I'd be willing to do > and support at least on the Plone level. For Zope2 itself some more > conditional code and optional support in some places might be the more > appropriate answer. > > Opinions? > > Hanno > > _______________________________________________ > Repoze-dev mailing list > [email protected] > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list [email protected] http://lists.repoze.org/listinfo/repoze-dev
