Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Mon, 09 Dec 2002 13:18:26 -0800 Heiichiro NAKAMURA <[EMAIL PROTECTED]> wrote: > 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: Sounds reasonable. USA is #1 in Internet Users with 160M. http://www.etforecasts.com/pr/pr1202.htm At least 21.91% of Internet users are CJK users. (Japan + China + South Korea + Taiwan) Since using UTF-8 for their pages is still not in common in these area, it is preferable to accomodate such workaround. --- Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Mon, 9 Dec 2002 10:13:16 +
Toby Dickenson <[EMAIL PROTECTED]> 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
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
DTML needs to be given the same amount of attention as it always has. For some bizarre reason, DTML makes sense in my headeven complicated logic... "Doctor! Do I need help?" It's one of the reasons I really liked Zope three years ago when starting with it The tag structure just made sense and was similar to a tool I used to get database calls and logic on a web page... "Long live DTML!!" - Original Message - From: "Chris McDonough" <[EMAIL PROTECTED]> To: "Tino Wildenhain" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 06, 2002 9:50 AM Subject: Re: [Zope] Re: [Zope-dev] Zope Book call for assistance > > erm... would "advanced DTML" not be the short sentence: > > "avoid DTML where you can"? ;) > > That'd be ok, except that DTML can of course do things that ZPT can't, > yada yada yada. > > > Btw. did you think of putting the whole DTML stuff at the end for > > reference only to help migrating old products and turn the > > whole thing a bit around so beginners get a clear path of > > Zope development? I found it a bit confusing when I edited > > the german translation of the 2.3 book a year ago. > > That's probably a good idea. But I think the rewritten chapters explain > when to use ZPT and when to use DTML. And DTML still needs to be given > some attention for the reason I say above... > > - C > > > > ___ > Zope maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
Jeffrey P Shell wrote:
But SQL Method DTML is very very very very nice. It has a lot of type
enforcement/safety measures (ie - autoquoting SQL Strings, ensuring
that a 'sqlvar type=float' operation is inserting a float); a lot of
*very* nice features for generating 'where' clauses (the sqltest
'optional' flag and the smart ' and ' tags that
won't render if an optional 'sqltest' preceding them was not
rendered); the 'sqltest multiple' feature is especially nice:
If foo is a blank string or empty list, that will render nothing.
If foo is a single string, that renders::
where foo = 'bar'
But if foo is a list of strings, that will render::
where foo in ('bar', 'baz')
Doing that programatically in Python is counterintuitive and awkward
(just as it was before the specialized 'dtml-sql___' tags in DTML).
For simple queries, doing it in the host programming language is not
bad. But for complex queries, it's very awkward to generate SQL.
It's almost as bad as generating HTML inside of a programming language
- it becomes difficult to maintain.
Yes, I think SQL methods are going to stick around. The downside is
there are some things that they SHOULD do that they dont, and that DTML
doesnt (to my knowledge) facilitate.
For example, ought to be able to check with
the underlying DA, and ask that DA to help it format its parameters.
Currently the render() method used by DTML seems to be presumed to be a
string, but what you want back is
("foo=:foo", ('foo',foo)) # or whatever all this foo foo sounds
like a poodle
so that any bind variables can be handled more efficiently by the DA.
Since each DA handles bind variables differently, it has to be involved
in the process to return a string with substitution text, and the value
to be substituted later. The DA's query method currently takes only a
string, but it should take a string and a concatenation of bind variables.
I remember looking at it and not wanting to get into trying to track
down where DTML would have to change to allow nonlinear results.
There may well be something in DTML processing that would make this
simple, I'm not very well versed on DTML processing internals.
--
Matt Kromer
Zope Corporation http://www.zope.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
On Saturday, December 7, 2002, at 04:11 AM, Tino Wildenhain wrote:
Hi Chris,
--On Freitag, 6. Dezember 2002 21:27 -0500 Chris McDonough
<[EMAIL PROTECTED]> wrote:
On Fri, 2002-12-06 at 19:13, Tino Wildenhain wrote:
These are exactly the things you shouldn't neither do in DTML
nor in ZPT :-)
What do you suggest people use for a templating language for email,
JavaScript, SQL, etc? I think it's too much to expect them to use
Python to do this (esp. wrt SQL methods).
Oh, is it? I'd rather like to write %(name)s %(value)d
then
Recently I read the python-dbi spec and its very nice to see
what you could do with the above form. There are even
standard ways to do multiple querys or function calls.
(Hope I can contribute a product for this as time permits)
But SQL Method DTML is very very very very nice. It has a lot of type
enforcement/safety measures (ie - autoquoting SQL Strings, ensuring
that a 'sqlvar type=float' operation is inserting a float); a lot of
*very* nice features for generating 'where' clauses (the sqltest
'optional' flag and the smart ' and ' tags that
won't render if an optional 'sqltest' preceding them was not rendered);
the 'sqltest multiple' feature is especially nice:
If foo is a blank string or empty list, that will render nothing.
If foo is a single string, that renders::
where foo = 'bar'
But if foo is a list of strings, that will render::
where foo in ('bar', 'baz')
Doing that programatically in Python is counterintuitive and awkward
(just as it was before the specialized 'dtml-sql___' tags in DTML).
For simple queries, doing it in the host programming language is not
bad. But for complex queries, it's very awkward to generate SQL. It's
almost as bad as generating HTML inside of a programming language - it
becomes difficult to maintain.
For E-Mail and Javascript templates I also find it less confusing
if I can use %(var)s form.
It's worth noting that there's a little known DTML format that's of
this style. Again - when doing simple insertion, %(var)s is not bad.
But once anything fancy comes into play - conditional insertion,
looping, etc - maintainability goes out the window when staying in the
host programming language. When I was evaluating Roundup
, I wanted to generate emails that looked as
good as the ones generated by Tracker. I had to write lines and lines
and lines of Python code to do it in order to replace a subclassed
method. There was no template that I could jigger around. (To be fair
to Roundup and Tracker both, I think customizing Tracker's email
messages is even harder).
I wouldn't mind seeing DTML.String re-emerge, which complements the
Python formatting string with DTML constructs to handle more advanced
templating needs. If you took a lot of the programming-language style
tags (dtml-try, dtml-return) out of DTML and normalized the expression
system (ie - to use TALES), you'd have a very usable system. The core
design concepts of DTML are good, it's just corrupted itself over the
years by stepping out of the plain-text templating language domain and
straddling the templating/programming language domains. DTML is even
used to generate DTML, by using the Extended Python Format String
syntax. This is how the 'Z Search Interface' custom reports are
generated.
As a general solution for texts one can use "file" which has an edit
tab for several releases of zope now. Then use it like this:
context.thefile.read() % context.REQUEST.form
or whatever seems appropriate to get values from.
E-Mail even gets clearer with the solution since you can easyly
loop and do whatever instead of multiple tags.
Life would be so much better if odd tags like could
just go away, and instead we had 'SMTP Methods' or something like that
- mail specific templates that are bound to a mailhost, with special
DTML tags (like the mime tag), similar to SQL Methods.
I love the SQL Method specific DTML tags. They make writing dynamic
SQL statements so easy, especially when compared to _any_ other system
that I've seen. It's a good showcase for DTML's ability to turn into a
domain specific templating language.
Regards
Tino
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Attempt to store an object from a foreign databaseconnection?
See "Mounted Transient Object Container Caveats" in
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Sessions.stx
for an explanation. The error you're getting means that somehow the
code is trying to store an object that has references to objects in one
ZODB database into another ZODB database (probably a mounted database).
On Mon, 2002-12-09 at 12:50, Stefan H. Holek wrote:
> Hi All!
>
> My situation is this: When creating CPS sites I sometimes see one of the
> tracebacks appended below.
>
> In its factory method (manage_addCPSSite) CPS creates two External Methods
> (cpsinstall & cpsupdate) inside a fresh CMF portal, and then executes
> these. During execution cpsupdate imports some components from .zexp files
> into portal tools.
>
> What does it mean when "the connection" is "closed"? Where does the
> "foreign database connection" come from in the first place? Is it probably
> not a good idea to run External Methods from inside a factory method?
>
> I can not all too reliably reproduce this but what I do is constantly
> create and delete CPS sites as I am customizing the mentioned External
> Methods. I also noticed that after a restart it works for a while, and then
> suddenly starts bombing out (after approx. 2 minutes). Once it is broken
> the error persists and I have to restart to be able to add a CPS site again.
>
> Happens with Zope 2.5.1 and 2.6.0 on Mac OS X and GNU/Linux
>
> Any hints appreciated,
> Stefan
>
> --
>
> 2002-12-09T17:02:13 ERROR(200) SiteError
> http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
> Traceback (innermost last):
> Module ZPublisher.Publish, line 98, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 39, in call_object
> Module Products.NuxCPS.CPSSite, line 79, in manage_addCPSSite
> Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
>- __traceback_info__: ((), {}, None)
> Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 101,
> in cpsinstall
> Module ZODB.Connection, line 504, in setstate
> RuntimeError: Shouldn't load state for '\x00\x00\x00\x00\x00\x00\x1fa' when
> the connection is closed
>
>
> 2002-12-08T23:30:12 ERROR(200) SiteError
> http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
> Traceback (innermost last):
> Module ZPublisher.Publish, line 98, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 39, in call_object
> Module Products.NuxCPS.CPSSite, line 81, in manage_addCPSSite
> Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
>- __traceback_info__: ((), {'langs_list': None}, (None,))
> Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 665,
> in cpsupdate
> Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 53,
> in tryimport
> Module OFS.ObjectManager, line 546, in _importObjectFromFile
> Module ZODB.ExportImport, line 79, in importFile
> Module ZODB.Transaction, line 222, in commit
> Module ZODB.Transaction, line 195, in commit
> Module ZODB.Transaction, line 256, in _commit_objects
> Module ZODB.Connection, line 387, in commit
>- __traceback_info__: (('Products.CMFCore.ActionsTool', 'ActionsTool'),
> '\x00\x00\x00\x00\x00\x00h\x11', '')
> InvalidObjectReference: Attempt to store an object from a foreign database
> connection
>
>
> 2002-12-09T00:24:58 ERROR(200) SiteError
> http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
> Traceback (innermost last):
> Module ZPublisher.Publish, line 98, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 39, in call_object
> Module Products.NuxCPS.CPSSite, line 81, in manage_addCPSSite
> Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
>- __traceback_info__: ((), {'langs_list': None}, (None,))
> Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 665,
> in cpsupdate
> Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 53,
> in tryimport
> Module OFS.ObjectManager, line 546, in _importObjectFromFile
> Module ZODB.ExportImport, line 79, in importFile
> Module ZODB.Transaction, line 222, in commit
> Module ZODB.Transaction, line 195, in commit
> Module ZODB.Transaction, line 256, in _commit_objects
> Module ZODB.Connection, line 382, in commit
>- __traceback_info__: (('Products.CMFCore.ActionInformation',
> 'ActionInformation'), '\x00\x00\x00\x00\x00\x00\x97\xf3', '')
> Module ZODB.Connection, line 507, in setstate
> Module ZODB.TmpStore, line 49, in load
> Module ZODB.FileStorage, line 619, in load
> Module ZODB.FileStorage, line 593, in _load
> POSKeyError: 97f3
>
> --
> Those who write software only for pay should go hurt some other field.
> /Erik Naggum/
>
> ___
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://
[Zope-dev] Attempt to store an object from a foreign database connection?
Hi All!
My situation is this: When creating CPS sites I sometimes see one of the
tracebacks appended below.
In its factory method (manage_addCPSSite) CPS creates two External Methods
(cpsinstall & cpsupdate) inside a fresh CMF portal, and then executes
these. During execution cpsupdate imports some components from .zexp files
into portal tools.
What does it mean when "the connection" is "closed"? Where does the
"foreign database connection" come from in the first place? Is it probably
not a good idea to run External Methods from inside a factory method?
I can not all too reliably reproduce this but what I do is constantly
create and delete CPS sites as I am customizing the mentioned External
Methods. I also noticed that after a restart it works for a while, and then
suddenly starts bombing out (after approx. 2 minutes). Once it is broken
the error persists and I have to restart to be able to add a CPS site again.
Happens with Zope 2.5.1 and 2.6.0 on Mac OS X and GNU/Linux
Any hints appreciated,
Stefan
--
2002-12-09T17:02:13 ERROR(200) SiteError
http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.NuxCPS.CPSSite, line 79, in manage_addCPSSite
Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
- __traceback_info__: ((), {}, None)
Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 101,
in cpsinstall
Module ZODB.Connection, line 504, in setstate
RuntimeError: Shouldn't load state for '\x00\x00\x00\x00\x00\x00\x1fa' when
the connection is closed
2002-12-08T23:30:12 ERROR(200) SiteError
http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.NuxCPS.CPSSite, line 81, in manage_addCPSSite
Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
- __traceback_info__: ((), {'langs_list': None}, (None,))
Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 665,
in cpsupdate
Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 53,
in tryimport
Module OFS.ObjectManager, line 546, in _importObjectFromFile
Module ZODB.ExportImport, line 79, in importFile
Module ZODB.Transaction, line 222, in commit
Module ZODB.Transaction, line 195, in commit
Module ZODB.Transaction, line 256, in _commit_objects
Module ZODB.Connection, line 387, in commit
- __traceback_info__: (('Products.CMFCore.ActionsTool', 'ActionsTool'),
'\x00\x00\x00\x00\x00\x00h\x11', '')
InvalidObjectReference: Attempt to store an object from a foreign database
connection
2002-12-09T00:24:58 ERROR(200) SiteError
http://127.0.0.1:8084/manage_addProduct/NuxCPS/manage_addCPSSite
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.NuxCPS.CPSSite, line 81, in manage_addCPSSite
Module Products.ExternalMethod.ExternalMethod, line 231, in __call__
- __traceback_info__: ((), {'langs_list': None}, (None,))
Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 665,
in cpsupdate
Module /Users/zope/w4/Products/NuxCPS/Extensions/cpsinstall.py, line 53,
in tryimport
Module OFS.ObjectManager, line 546, in _importObjectFromFile
Module ZODB.ExportImport, line 79, in importFile
Module ZODB.Transaction, line 222, in commit
Module ZODB.Transaction, line 195, in commit
Module ZODB.Transaction, line 256, in _commit_objects
Module ZODB.Connection, line 382, in commit
- __traceback_info__: (('Products.CMFCore.ActionInformation',
'ActionInformation'), '\x00\x00\x00\x00\x00\x00\x97\xf3', '')
Module ZODB.Connection, line 507, in setstate
Module ZODB.TmpStore, line 49, in load
Module ZODB.FileStorage, line 619, in load
Module ZODB.FileStorage, line 593, in _load
POSKeyError: 97f3
--
Those who write software only for pay should go hurt some other field.
/Erik Naggum/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Monday 09 December 2002 2:20 am, Heiichiro NAKAMURA wrote:
> On Sun, 8 Dec 2002 21:58:16 +
>
> Toby Dickenson <[EMAIL PROTECTED]> wrote:
> > On Thursday 05 December 2002 9:36 pm, Toby Dickenson wrote:
> > > Yes, I have an idea. I hope to find time to flesh it out early next
> > > week.
> >
> > I propose:
>
> Here is my understanding of your proposal:
>
>
>
> 1. "management_page_charset" property for non-Latin-1
>
> Affected application: ZMI only
> Limitation:
>- Standard Objects in Zope (such as "title" property) must be
> Non-Unicode.
Yes, if using management_page_charset.
>- All objects must be Non-Unicode in order to work in ZMI.
To be precise, all objects rendered on the management page must be plain 8bit
strings.
>- 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.
yes
>- REQUEST.set('management_page_charset','UTF-8') does not work
> when 'management_page_charset' is set as global property.
That is the current, broken behaviour. I propose that REQUEST.set overrides
the global property. Note that no standard ZMI page will do so, except the
'properties' tab explained below.
> Homework (new issues):
>- define the safe steps of implementation of Unicode Support
>- find a way of smooth migration of MBCS-to-Unicode
Yes. There is nothing zope-specific about this being hard ;-)
>
>
>
> 2. Behaviour of handling of text in ZMI
Not all of ZMI - this is just the 'Properties' tab.
>
> When UnicodeType Properties are contained:
> - internal representation: 'UCS-2/UTF-16' if UnicodeType(ex. ustring)
> 'Latin-1' if not UnicodeType(ex. string)
> - encoding of output data: 'Latin-1'
No, output over http will be utf8.
> - encoding of input data: 'Latin-1'
If you mean input from the browser when a property changes, no. it will use
utf8.
> When UnicodeType Properties are NOT contained:
> - encoding of input data: any
yes, the same as all other ZMI pages. latin-1 by default, and can be overidden
by management_page_charset.
> - internal representation: same as input (no conversion)
> - encoding of output data: same as internal (no conversion)
>
> Limitation:
> - Non-Latin-1 value cannot be used when creating the first Unicode
>Property.
>
>
> (Any correction is welcomed)
>
> I'll ask power users of Japan-Zope-User-Group-ML about opinions
> regarding to the proposal.
>
> > but I
> > suggest that compatability with this feature should not hold back any
> > future enhancements to the ZMI which rely on using unicode)
>
> I guess this statement is somewhat ambiguous. Probably we could say
> something like that? :
>
> 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/limitation can be evaluated in order to
> avoid hassle implementation integrated into the official version.
yes
> 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.
> until
> the Unicode Support gets matured enough to handle Unicode object
> with all languages/encodings.
Yes. There are several places in the ZMI that could benefit from
'unicodization'. At the moment I suspect it will be difficult to implement
these improvements while retaining support for management_page_charset.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
