[Zope-dev] AccessControl bug fixed
Hello, I found a bug in ZopeSecurityPolicy and fixed it. http://svn.zope.org/AccessControl/trunk/src/AccessControl/ZopeSecurityPolicy.py?rev=127548&r1=113657&r2=127548 Is it possible to release new version? Regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hello, On Fri, 05 Feb 2010 15:29:03 -0300 Roberto Allende wrote: (snip) > Regarding DTML... i wonder if it dtml purpose doesn't overlap with > tal/metal or even viewlets. If that's the case we wouldn't provide > 'One-- and preferably only one --obvious way to do it' and for non Dutch > newbies :P is kinda confusing because end up with situations like > 'you've to learn it but you won't use in-real-projects'. > > So, wouldn't make sense to have DTML in an separated component and make > its use optional ?. DTML is still very useful if we make non-xml stuff like SQL, CSS, JavaScript etc. And I have used it in many real projects for about 7 years. If there is something(online document?) which make new users confused, it would be better to fix it. ZPT is useful to generate xml/html documents, DTML is useful to generate non-xml documents. Regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hi, On Thu, 04 Feb 2010 00:59:52 -0300 Roberto Allende wrote: (snip) > Probably at this point of the conversation is the right moment to ask if > it would make sense to improve Zope2's ZMI, removing frames and perhaps > DTML code and probably removing all the dtml from zope2. I'd say that removing all the dtml from zope2 is too much. I know that there are many web sites which have used dtml for a long time. And also dtml works quite well without any serious problems. Regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hi, On Wed, 03 Feb 2010 14:20:08 +0100 Tom Gross wrote: > Hi all, > > with HTML5 the frame-elements will die. It will probably take some > years before the browser-support of HTML4 will stop, but still. Are > there any alternative implementations for the Zope2-ZMI? > > There is a package zmi.core in the Zope-svn, but except some links to > other packages there is nothing in it. Is the package alive and what's > the targeted platform: Zope2, BlueBream, grok? I have been working for zmi.core for several months and it is still under construction(sorry). The target was Zope3 and now it's BlueBream. Of course we can use it for grok. Zope2's ZMI is different. Regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hi, On Wed, 22 Apr 2009 09:48:40 +0200 Martijn Faassen wrote: > Hey, > > Roger Ineichen wrote: > > I think there is a little confusion about which package depends on > > each other. > > > > Right now there is a zmi.core package this package should > > contain core parts without to much dependency. After that > > we need several zmi.* packages which are replacements for > > each zope.app.* package. right? > > Right. Note that I'm against making too many zmi.* packages right now, > keep it all in a few packages now. > > Concerning dependencies, let's first talk about zope.container: > > zmi should depend on zope.container > > zope.app.container.browser should have backwards compatibility imports > from zmi, and zope.app.container should depend on zmi > > Now let's talk about a package that *hasn't* been factored away from > zope.app.* yet, such as zope.app.file: > > in this case, zmi would depend on zope.app.file but > zope.app.file.browser would depend on zmi. That's a circular dependency, > which we should break as soon as possible by moving zope.app.file's > content objects to zope.file or something like that. I see, this is very clear. BTW, what do you think of zope.app.form? As far as I know, it has some basic interfaces like IInputWidget and IDisplayWidget, and they are used by various packages. Then I don't see any reason to leave them under zope.app.form. So, I think maybe we could also move them to zope.form or somewhere generic package after we finish zmi package. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hi, On Tue, 21 Apr 2009 18:40:51 +0200 Martijn Faassen wrote: > >> Or should we break BBB and let people know that they have to install > >> zmi.core for zmi support? (I think so) > > > > I won't break BBB as much as possible, at least I'd like to keep persistent > > data compatibility... > > But the ZMI is all views, right? What is persistent? Yes, you're right. It's my mistake...We would not have any persistent data in zmi package. > > For now, I don't have clear image yet. I'm checking all zope.app.* packages > > and make > > sure all tests pass. And maybe I will review current package dependencies. > > For that, you might want to investigate the z3c.recipe.depgraph recipe > to generate dependency graphs. To try it against trunks you need to add > them to 'develop' in your buildout.cfg Oh I did not know that. Thanks. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hi Roger, Thank you very much for your comment, and sorry for my late reply. I did not receive your post I don't know why... > > Betreff: Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams > > > > Hi, > > > > I just start working on maintaining ZMI and make it optional package. > > For now, it is easy to participate, just porting zope.app.* > > (I already list up targets as directories in zmi.core) and > > make sure that existing tests succeeds. > > Can you tell a little bit about what you mean with tests succeed? > Should the test in the existing package succeed? But this whould > mean that the old packages we move the zmi parts from needs to depend > on the new zmi.core package. > > Should the old zope.app.* package depend on the new zmi.core package? > (I think not) No. But zmi.core might depend on zope.app.* packages. > Or should we break BBB and let people know that they have to install > zmi.core for zmi support? (I think so) I won't break BBB as much as possible, at least I'd like to keep persistent data compatibility... > If so, then the test should succeed in the new zmi.core packages, right? Yes, my intention was to make sure that after we copy files from zope.app.* to zmi.core.*, then existing tests which were originally in zope.app.* have to work in zmi.core.*. > Can you write down some comment how we sould do the refactoring > like: > > - move the zmi part from a zope.app.* package to > the new zmi.core.* package. Yes. > - make sure the test pass in both packages. The zmi > test should all get moved to the new zmi.core.* package > Probably enhance the tests since the zmi part was not very > well tested. Yes. > - release the zmi.core package after each package move > or at least before the zope.app.* package get released > > - bump up the zope.app.* package version (full not partial) > e.g. 3.5.1 to 3.6.0 Hmm, I'm not sure yet... > Not sure if the above is correct. Please change if not. > It is at least only correct if we break BBB and move the zmi > completly out of all zope.app packages to zmi.core. > > And probably we should also implement a testing layer setup > which all test in zmi.core can share/use. Sounds good idea. For now, I don't have clear image yet. I'm checking all zope.app.* packages and make sure all tests pass. And maybe I will review current package dependencies. After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm very slow for some reasons, I cannot make an exact schedule yet. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hi, I just start working on maintaining ZMI and make it optional package. For now, it is easy to participate, just porting zope.app.* (I already list up targets as directories in zmi.core) and make sure that existing tests succeeds. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hi, On Fri, 17 Apr 2009 13:09:05 +0200 Fabio Tranchitella wrote: > To be honest, zope3 (as it is today) is a nice platform for me and for my > company to build web applications (and, in general, the ZCA is a nice > platform for building not-only-web applications), and it would be a shame > to loose it. ZCA will be improved by ZTK, so I don't worry. > To make explicit: I am not talking just about maintaining the ZMI, I'm > talking about making zope3 a *real* user-friendly web framework, as (for > example) grok is already right now. For me, my main purpose is maintaing the ZMI as an application server on ZTK, because I find it still useful for maintenance/configuration on the spot for example. But making Zope3(though it is still ambiguous for me)/ZTK user- friendly sounds a very nice idea. I could imagine a lot of packages might makes beginners shrink a bit, although we already have nice books. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
On Wed, 15 Apr 2009 14:10:44 +0200 Martijn Faassen wrote: > > Then I'll take this way for now. Maybe z3c.zmi.core would be good? > > Flat is better than nested (see the Zen of Python). I'd say go for > "zmi.core"; z3c isn't necessary. Thanks. I will use the name "zmi.core" and will commit initial draft this weekend. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hi, On Wed, 15 Apr 2009 09:37:33 +0200 Martijn Faassen wrote: > Perhaps one way to make the ZMI and optional package is to aggregate the > relevant ZMI code into a smaller amount of packages (or a single > package), for instance zmi.core. The benefit of doing that is that it > should be possible to evolve the code slowly. You could still support > the zope.app.* packages compatibility by putting imports from > zope.app.something.browser to zmi.core. Then I'll take this way for now. Maybe z3c.zmi.core would be good? Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hi, On Tue, 14 Apr 2009 18:34:47 +0200 Martijn Faassen wrote: > So, who finds the Zope 3 ZMI useful? What parts of it do you find > useful? Are you interested in helping maintain it? For me, the ZMI is useful to managing local components, security settings, making views for ad hoc changes etc. I think it could be an optional package like grokui.admin. I'm interested in maintenance it. Best regards, -- Yusei TAHARA ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Notify event for getWSGIApplication?
Hello. On Wed, 2 Jan 2008 19:13:24 +0100 Yusei TAHARA <[EMAIL PROTECTED]> wrote: > I'd like to add a new event for getWSGIApplication. > (the name is like WSGIPublisherApplicationCreatedEvent?) I've added the event in zope.app.wsgi package. Thank you, -- Yusei TAHARA <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Notify event for getWSGIApplication?
Hello, I'd like to add a new event for getWSGIApplication. (the name is like WSGIPublisherApplicationCreatedEvent?) Because, now zope3 uses no particular web server but can use any wsgi server and I'd like to make a internal webserver calling facility with a generic way. I'd appreciate any comments. Thank you very much. -- Yusei TAHARA <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. > I am currently looking at getting this into 2.6.1 or 2.6.2. I would > appreciate confirmation that you are all happy with this combination > of patches. Thank you:-) BTW, I was asked for upload my patch on collector. Could you put it in a issue 737 page? I don't permit to upload it. Regards. -- Yusei ___ 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.
Hi.
> 2.6.2 is a realistic target.
Sure.
I tried to your patch 03-properties.diff, then I found two problems.
1. browsers autodetection make a mistake.
makes some web browsers confuse, it ignores meta tag
charset and autodetect UTF8.So I will remove , when
REQUEST has another charset value.
2. "management_page_charset_tag" really needs?
Because "management_page_charset" is approach of not using unicode.
But management_page_charset_tag exists, REQUEST will convert strings to
unicode strings.field2string has not convert_unicode method, then raise
unicodeerror. It is contradiction.
HTTPRequest.py line:499
if flags&CONVERTED:
try:
if character_encoding:
# We have a string with a specified character encoding.
# This gets passed to the converter either as unicode, if it can
# handle it, or crunched back down to latin-1 if it can not.
item = unicode(item,character_encoding)
if hasattr(converter,'convert_unicode'):
item = converter.convert_unicode(item)
else:
item = converter(item.encode('latin-1'))
I made a patch for fix those problems. It looks good work on my zope.
Regards.
--
Yusei Tahara"So it goes"
[EMAIL PROTECTED]
properties.diff
Description: Binary data
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi.
> Probably os.environ.get('Z_SOMETHING') might be a better way than
> locale.getlocale()[1], because using locale.getlocale()[1] means that
> the behaviour of Zope will be changed implicitly, whereas
> os.environ.get('Z_SOMETHING') is more explicit for the users, thus
> less confusing..
Nice idea.
We can get environment value everywhere in Zope.
it will be easy to make patch:-)
+1
Regards
--
Yusei
___
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.
Hi. Sorry, I noticed that my patch is defective. It is failure when object has own Property:-( -- Yusei ___ 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.
Hi. > > What thing is concretely "some details"? > > The fix to this situation is more complicated than removing a ":utf8:" from > somewhere that it shouldnt be. Im sure you know this. At this point Zope2.6.x, my guess is that would not clear up this problem completely.But my patch allows to use both type string and ustring when a user set right encoding name to "management_page_charset". This is a temporary trick, but works well. > > I'm very interested in Zope development, especially i18n. > > So I would like to contribute something about it:-) > > The patch you mentioned? I want to tackle this complicated problem in Zope development rather than make my own patches. Because the i18n is more benefit for minority languages such as japanese than major one.I need it very much. Thank you. -- Yusei ___ 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.
Hi. > > I made monkey patch for myself, when management_page_charset is not > > "UTF-8", this patch remove ":utf8:" from non unicode type input field. > > because if input values are not latin-1, then unicode error raised. > > > > I think that every encoding can be used it satisfactory:-) > > > > Please consider whether it can merge into Zope2.6.1. > > There are some details missing from your explanation, but hopefully not from > your patch. where do I find it? What thing is concretely "some details"? I'm very interested in Zope development, especially i18n. So I would like to contribute something about it:-) Thank you. -- Yusei Tahara"So it goes" [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.
Hi. > 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? yes. why I don't want to use ustring, because there are two problems for me. 1. the original encoding is not clear anymore. It does not know that it will change at once. there is no encoding which raise unicode error other than utf-8. but utf-8 is not common encoding in japanese. almost all PDAs or cellular phones are not supporting utf-8. Probably, automatic encoding detection will be required in order to become practical. 2. ustring can not join or replace to 8-bit strings other than ascii. I have an same experience in Plone i18n with Localizer and TranslationService. > 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? yes. If I input values by PythonScript without using property tab, it works well. > 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. I think management_page_charset is very useful, if it function correctly. > 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. I made monkey patch for myself, when management_page_charset is not "UTF-8", this patch remove ":utf8:" from non unicode type input field. because if input values are not latin-1, then unicode error raised. I think that every encoding can be used it satisfactory:-) Please consider whether it can merge into Zope2.6.1. Thank you -- Yusei Tahara"So it goes" [EMAIL PROTECTED] properties.dtml Description: Binary data
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
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 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. if don't allow to use string type in properties, I regret that I would continue to use zope2.5.1 or make my own monkey patches for after this. I'm sorry to my BAD English. Thank you. -- Yusei TAHARA ___ 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] [ANN] Proposal: Integration of reStructuredText into Zope
Hi. +2 I like this Proposal very much. It allow to use multibyte charctor in document:-) Regards. ___ 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] Re: [Zope-2.6.0b1] Property Problem
Hello. > > > and Folder title attribute is "string" not "ustring". > > > > so change it. > > Hmm the 'title' property of Folder is not deletable. Yes.. But, ustring is not best solution for me. Because, utf8 is not common encoding in japan.There are three japanese encodings, and "euc-jp" is always used for web application.Native python string is only type for using "euc-jp" correctly. So, I need to use string type for japanese in zope2.6 very much. I read property and zpublisher source code, and then I found resolution in my own way. -- OFS/dtml/properties.dtml -- about 2 line about 250 line --- This code avoid to encode non latin-1 encoding charctor to latin-1. And it can use unicode without interruption. ofcourse, it also needs to implement this logic in other input form tags like text or lines field and so on. I hope to solve this problem before zope2.6 release.This is really important things for i18n. Sorry to my bad English. Thank you very much. -- Yusei Tahara"So it goes" [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 )
[Zope-dev] [Zope-2.6.0b1] Property Problem
Hello.
I have a problem with property tab on zope 2.6 branch,
I can't add/edit properties in japanese.
Because, fixing "latin-1" for unicode decoding in some place.
japanese or other asian language are not latin-1 encoding,
so management_page_charset won't help me.
and Folder title attribute is "string" not "ustring".
if nothing is done, I should make a monkey patch for every zope
update, this is very bad
Yusei
#ZPublisher/ZConverters.py line:19
def field2string(v):
if hasattr(v,'read'): return v.read()
elif isinstance(v,UnicodeType) :
return v.encode('latin1') #it cause this problem...
else:
return str(v)
#ZPublisher/HTTPRequest.py line:501
if character_encoding:
# We have a string with a specified character encoding.
# This gets passed to the converter either as unicode, if it can
# handle it, or crunched back down to latin-1 if it can not.
item = unicode(item,character_encoding)
if hasattr(converter,'convert_unicode'):
item = converter.convert_unicode(item)
else:
item = converter(item.encode('latin1'))
else:
item=converter(item)
#OFS/dtml/properties.dtml line:250
----
--
Yusei Tahara"So it goes"
[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 )
