Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
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.
- All objects must be Non-Unicode 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.
- REQUEST.set('management_page_charset','UTF-8') does not work
when 'management_page_charset' is set as global property.
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
When UnicodeType Properties are contained:
- encoding of input data: 'Latin-1'
- internal representation: 'UCS-2/UTF-16' if UnicodeType(ex. ustring)
'Latin-1' if not UnicodeType(ex. string)
- encoding of output data: 'Latin-1'
When UnicodeType Properties are NOT contained:
- encoding of input data: any
- 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.
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, until
the Unicode Support gets matured enough to handle Unicode object
with all languages/encodings.
---
Heiichiro NAKAMURA <[EMAIL PROTECTED]>
On Sun, 8 Dec 2002 21:58:16 +
Toby Dickenson <[EMAIL PROTECTED]> wrote:
> On Thursday 05 December 2002 9:36 pm, Toby Dickenson wrote:
> > On Thursday 05 December 2002 8:41 pm, Heiichiro NAKAMURA wrote:
> > > Does anyone have any other idea for the Collector 623 issue?
> > > I hope better ideas will be posted..
> >
> > Yes, I have an idea. I hope to find time to flesh it out early next week.
>
> I propose:
>
> 1. Currently you can set a management_page_charset property to override the
> global assumption that legacy ZMI pages are latin1. This is a hack that
> happens to mostly work by accident, provided your ZMI pages do not encounter
> a unicode object. I propose promoting this to a standard documented feature.
>
> Is there anyone who actually uses this feature who can contribute some
> documentation?
>
> (Note that feature will never work with pages that do encounter unicode
> objects. This means Zope should try to avoid gratuitous unicode usage, but I
> suggest that compatability with this feature should not hold back any future
> enhancements to the ZMI which rely on using unicode)
>
>
> 2. The documented way of setting a ZMI-page-specific encoding is
> REQUEST.set('management_page_charset','UTF-8'). Currently
> management_page_charset as a global property will override this page specific
> setting. This is a bug that needs to be fixed.
>
>
> 3. I propose changing the encoding used by the standard 'Properties' ZMI page.
> Currently it uses UTF8 always, and assumes that 8bit string properties are
> latin1. I propose that this policy is used only if a unicode property has
> already been defined on this object. If it has not, it uses the same encoding
> policy as every other ZMI page - that is the value of the
> management_page_charset property, or latin-1 if it has not been set.
>
> A disadvantage of this chan
[Zope-dev] slightly offtopic: Publish/Subscribe mechanisms and Zope.
All, Some time ago a Zope developer (a Zope Corp employee) contacted me with regards to my pyKnowNow microserver that allowed Python to be a fully fledged part of a KnowNow (http://developer.knownow.com) network. Since I can't remember who that was, typical, I'm posting this in the hope that it jogs a few memories. It may also be of interest to others :). The point of this mail is that a newish project on SourceForge, http://mod-pubsub.sf.net, is now available via cvs. This is basically a repackaging as opensource of an earlier, but it seems quite complete, version of KnowNow. The best part is that as well as the Apache Perl cgi based server there is also a complete alpha quality version of a server written in Python based on asyncore. This seems like a good opportunity to start looking at Zope and pubsub again. The mod_pubsub stuff also has a Javascript microserver. This has huge possibilities for interactive web apps, presence, instant messaging, chat, et al. I apologise if this is too far off topic but thought that people may be interested :). Phil Harris [EMAIL PROTECTED] ___ 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 Thursday 05 December 2002 9:36 pm, Toby Dickenson wrote:
> On Thursday 05 December 2002 8:41 pm, Heiichiro NAKAMURA wrote:
> > Does anyone have any other idea for the Collector 623 issue?
> > I hope better ideas will be posted..
>
> Yes, I have an idea. I hope to find time to flesh it out early next week.
I propose:
1. Currently you can set a management_page_charset property to override the
global assumption that legacy ZMI pages are latin1. This is a hack that
happens to mostly work by accident, provided your ZMI pages do not encounter
a unicode object. I propose promoting this to a standard documented feature.
Is there anyone who actually uses this feature who can contribute some
documentation?
(Note that feature will never work with pages that do encounter unicode
objects. This means Zope should try to avoid gratuitous unicode usage, but I
suggest that compatability with this feature should not hold back any future
enhancements to the ZMI which rely on using unicode)
2. The documented way of setting a ZMI-page-specific encoding is
REQUEST.set('management_page_charset','UTF-8'). Currently
management_page_charset as a global property will override this page specific
setting. This is a bug that needs to be fixed.
3. I propose changing the encoding used by the standard 'Properties' ZMI page.
Currently it uses UTF8 always, and assumes that 8bit string properties are
latin1. I propose that this policy is used only if a unicode property has
already been defined on this object. If it has not, it uses the same encoding
policy as every other ZMI page - that is the value of the
management_page_charset property, or latin-1 if it has not been set.
A disadvantage of this change is that it will not be possible to set a
non-latin-1 initial value when creating the first unicode property. I think
this is just about acceptable.
___
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] Non Bloating Page Counter
On Wednesday 06 November 2002 8:33 am, Janko Hauser wrote: > Just an idea from the 'could-be-done-if-needed-department'. Generally > there is quite often the need to have non-undoable properties in > different objects of a site. There is one way to store it in the > temporary storage, which is ram based, and not shared between ZEO > instances. But if a second non-undoable storage is mounted it could be > stored there and could be shared between ZEOC. > > To make this more transparent, one could perhaps implement something > like a special propertysheetobject, which stores its properties in this > mounted storage. > > Is there anything obviously wrong with this idea? the problem is that cross-storage references are tricky. Mixing undoable and non-undoable *objects* in the same storage is on the to-do list for DirectoryStorage, http://dirstorage.sourceforge.net ___ 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] manage_roleForm (bug?)
Brian R Brinegar wrote: Now, my question is if this is a bug within RoleManager or a bug within the individual products? I may be wrong, but I think this might be a reflection on the way the Zope security system works... cheers, Chris ___ 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 )
