[Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Heiichiro NAKAMURA
nheiich@quantumfusion.com
Mon, 09 Dec 2002 13:18:26 -0800
On Mon, 9 Dec 2002 10:13:16 +0000
Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
> > 2. Any experimental enhancements to the ZMI which rely on using unicode
> > must be integrated into the official version in the manner that
> > it doesn't affect the behaviour of 'legacy' applications,
>
> I disagree. I dont want to block a good new feature from Zope 2.x (x>=7)
> simply because it uses unicode in a way that is incompatible with the
> management_page_charset property. Thats what 'legacy' means.
I see. How about that then?
2. Whenever any experimental enhancements to the ZMI which rely on
using Unicode is to be integrated, create an new tab and put these
features in that page in order:
- to provide a choice of not to use new features so that
you can avoid serious problems which may be caused by them, thus
traditional implementations (ex. 'Contents', 'View', 'Properties'
tabs) works fine and their behaviours aren't affected by new features.
- to make users be able to distinguish which features are new-and-risky
easily, so that users can avoid using potentially hazardous
implementation more easily. Maybe it's better to change the bgcolor
of these tab and put the warning message on top of the new pages
of these features.
This is a tentative limitation on UI design, and should be removed
after the Unicode Support gets matured enough to handle Unicode object
with all languages/encodings.
My intension is:
- Not to block the integration of new features which use Unicode
- Not to make Zope un-usable for Non-Latin-1-language-native users:
- At least the essential features should work for anyone.
- It's OK if the new nice-to-have features do not work.
I revised some parts of my note based on your input. Here's the new one:
1. "management_page_charset" property for non-Latin-1 in ZMI
------------------------------------------------------------------------
Purpose:
- Use "management_page_charset" property to use Non-Latin-1
text as Non-Unicode (plain-8bit-string) text in ZMI.
Affected application: ZMI only
Limitation:
- Standard Objects in Zope (such as "title" property) must be
Non-Unicode (if using management_page_charset).
- All objects in the management page must be plain-8bit-string
in order to work in ZMI.
- If there is even one Unicode object there, all data will be
assumed as 'Latin-1' and non-Latin-1 data cannot be used in
any object.
- In the current release (original 2.6.0 release)
REQUEST.set('management_page_charset','UTF-8') does not work
when 'management_page_charset' is set as global property.
This limitation will be fixed: the value of REQUEST.set
overrides the global property (in 'properties' page only).
Homework (new issues):
- define the safe steps of implementation of Unicode Support
- find a way of smooth migration of MBCS-to-Unicode
------------------------------------------------------------------------
2. Behaviour of handling of text in ZMI's 'Properties' page.
------------------------------------------------------------------------
When UnicodeType Properties are contained:
- encoding of HTTP input data: 'UTF-8'
- internal representation: 'UCS-2/UTF-16' if UnicodeType(ex. ustring)
'Latin-1' if not UnicodeType(ex. string)
- encoding of HTTP output data: 'UTF-8'
When UnicodeType Properties are NOT contained:
- encoding of HTTP input data: any
(default:Latin-1, can be overridden by 'management_page_charset')
- internal representation: same as input (no conversion)
- encoding of HTTP output data: same as internal (no conversion)
Limitation:
- Non-Latin-1 value cannot be used when creating the first Unicode
Property.
------------------------------------------------------------------------
3. Guideline on the future enhancements to the ZMI which rely on using Unicode
------------------------------------------------------------------------
3.1. Any future enhancements to the ZMI which rely on using Unicode
should be carefully defined, examined, evaluated and feasibility-tested
so that all issues/limitations can be clarified and the consequent
impact of these issues/limitations can be evaluated in order to
avoid hassle implementation integrated into the official version.
3.2. Whenever any experimental enhancement to the ZMI which rely on
using Unicode is to be integrated, create new tabs and put these
features in these pages in order:
- to provide a choice of not to use new features so that
you can avoid serious problems which may be caused by them, thus
traditional implementations (ex. 'Contents', 'View', 'Properties'
tabs) works fine and their behaviours aren't affected by new features.
- to make users be able to distinguish which features are new-and-risky
easily, so that users can avoid using potentially hazardous
implementation more easily. Maybe it's better to change the bgcolor
of these tabs and put the warning message on top of the new pages
of these features.
This is a tentative limitation on UI design, and should be removed
after the Unicode Support gets matured enough to handle Unicode object
with all languages/encodings.
------------------------------------------------------------------------
(Any correction is welcomed)
Regards,
---
Heiichiro NAKAMURA <nheiich@quantumfusion.com>