Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
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]
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] post-publishing hook
Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? Thanks for helping, cheers, Carlo. ___ 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] Re: [Zope] post-publishing hook
Hi Carlo, --On Freitag, 29. November 2002 13:07 +0100 Carlo Giomini [EMAIL PROTECTED] wrote: Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? May be. But what are you trying to do? Perhaps there is a better solution available if we know the whole picture. 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 )
[Zope-dev] Re: [Zope] post-publishing hook
On Friday 29 November 2002 12:07 pm, Carlo Giomini wrote: Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? Yes, but its nasty. Look at ZPublisher.BaseRequest._hold ___ 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] Bugfix release?
On Wednesday 27 November 2002 5:50 pm, Brian Lloyd wrote: FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta. Im not sure this is a good plan. Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow. Sure, ___ 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] [ANN] Proposal for better support of international dateforms inDateTime
http://dev.zope.org/Wikis/DevSite/Proposals/BetterEuropeanDateTimeSupport Feel free to comment. Cheers, Andreas - -Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - -Life is too short to (re)write parsers - - ___ 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] post-publishing hook
On Fri, Nov 29, 2002 at 01:07:24PM +0100, Carlo Giomini wrote: Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? There is a way, but I find it somewhat ugly/hackish. But Shane uses it in CookieCrumbler, so it must be good ;) You can pass an instance to REQUEST._hold, which should be deleted when REQUEST gets deleted, so at the complete end of the request. This means you can pass an instance to a class that defines a __del__ method, where you can do your work. You'll be working outside the REQUEST transaction at that moment, so please keep that in mind when modifying objects. Cheers Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- T +31-20-4688336 F +31-20-4688337Linux/Web/Zope/SQL/MMBase W http://www.amaze.nlE [EMAIL PROTECTED] Network Solutions W http://vanderwijk.info E [EMAIL PROTECTED] Consultancy PGP http://vanderwijk.info/pgp -=- ___ 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] post-publishing hook
On 11/29/2002 01:33 PM, Ivo van der Wijk wrote: On Fri, Nov 29, 2002 at 01:07:24PM +0100, Carlo Giomini wrote: Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? There is a way, but I find it somewhat ugly/hackish. But Shane uses it in CookieCrumbler, so it must be good ;) Reliable and good are not necessarily the same thing. :-) Since the only way ZODB connections ever get closed in a standard Zope setup is through the request.hold() mechanism, you can be sure that if Zope is working at all, the side effects of request.hold() are working. Relying on side effects can be dangerous, though. You'll be working outside the REQUEST transaction at that moment, so please keep that in mind when modifying objects. In fact, the database connection might already be closed. If you need to read or write the ZODB, you might have to open a private connection and close it before returning. Ugh. Shane ___ 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] Re: Bugfix release?
I'll drop in another (and final) plug for the one-line change needed to undo the harmful http://collector.zope.org/Zope/432 . Andreas, it looked like you were going to fix this for 2.6.0 . Did it slip through the cracks or are you having second thoughts ? Recap: Andreas made ' take precedence over everything including sgml tags, breaking dtml python expressions in zwiki stx pages. I've since found an easy way to work around this for zwiki, but it adds one more behavioural difference code duplication between zwiki's and zope's stx. Better to avoid this. Regards - Simon ___ 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 TaharaSo it goes [EMAIL PROTECTED] properties.dtml Description: Binary data
