On Friday 29 November 2002 5:44 am, Yusei Tahara wrote:
> Hi.
> > The right approach is to make it possible to change the title property to
> > a unicode string. All my custom products have this already, but it is a
> > deficiency in the standard Zope types such as 'Folder' that their titles
> > type> can not be changed.
> This approach is not useful for me.
> I often use zope with RDB like MySQL.
> generally japanese encoding text is in RDB.
> so if object properties are unicode string,
> I always encode it before publishing.
> <title tal:content="python:here.title.encode('euc-jp')">TITLE</title>
> because, it always mix in RDB data(japanese) and
> properties(python unicode string) in one page.
> certainly I will be faced with this ustring problem everytime.
> Japanese charactor is not ascii,
> so if I do not encode ustring before publishing,raise unicode error.

The unicode changes were designed to cope with your scenario, so I would like 
to explore the limits of where this approach has gone wrong.

As I understand it, you dont want to do anything in unicode. You store, 
manipulate, process, and output strings as 8-bit pre-encoded strings. You  
are making an assumption that these 8-bit strings use some specific character 
encoding. The scope of this assumption is quite broad. It has to cover:
1. All strings stored by your ZODB
2. All strings stored by your RDB.
3. All processing performed by Zope products. (must follow your assumptions, 
or be encoding neutral)

Anything that beaks these assumptions will need special treatment.

Am I right so far?

Im sure you are aware of the limitations of this approach - they are the 
limitations that unicode was designed to break (not Zope's unicode, but 
unicode in general). Im not sure your approach is workable long term because 
an increasing number of Zope products will naturally use unicode so that they 
can store properties containing text across a range of scripts. Even if this 
is not workable long term, it was supposed to work in 2.6.

Zope's approach is that your application (excluding the ZMI for now) should 
work as in 2.5, provided you dont use any unicode values. Can you confirm 
that this is working OK?

Zope 2.5 left ZMI character encoding down to browser autodetection, and as a 
result most ZMI-controlled properties are encoding-neutral. For compatability 
with unicode pages, which are seen as the long term future, the ZMI has to 
specify *some* character encoding. By default in 2.6 this is latin-1, a 
change which I think was announced mid-way through the 2.5 development cycle. 
I understand that some users are very happy overriding this with a 
management_page_charset property on their root folder. Ive never used this, 
and it wasnt designed to work this way, but it looks like it works due to 
happy coincidence. Note that this doesnt work for management pages which 
explicitly set their own character encoding, or management pages which 
'accidentally' encounter a unicode string.

(Although this management_page_charset feature was not planned, I guess I will 
be supporting this feature if it is being used)

One area where this went wrong for you is the properties page, which is 
explicitly set to utf8 to allow unicode properties to be set. Im not yet sure 
on the best way to fix this for you, but I agree it needs fixing.

As far as I can tell this is the only area which should be causing you 
problems. Am I missing something?

(The 'title' problem I mentioned in a previous post is also a problem that 
needs fixing, but not one that affects you if you dont want to use unicode.)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to