September 2002 - Zope-Dev

understanding FORCE_PRODUCT_LOAD
by jeffrey 27 Sep '02

27 Sep '02

After a hell and back and hell and hell and back and hell and back and hell and back again morning trying to update a Zope 2.3.3 site (as ZEO client) to be a Zope 2.5.1 site (including installation of some new products), I finally re-discovered the magic of FORCE_PRODUCT_LOAD environment variable. The only reason I even remembered this variable existed was because of Chris McDonough mentioning it a long long time ago (before the new Zope Corp offices). Not only is it undocumented, it's undocumented incorrectly ;). At the end of doc/ENVIRON.txt, it's listed as FORCE_PRODUCT_RELOAD with the wording "unknown (Shane's Refresh product ???)". If someone with a deeper understanding of what this environment variable does - and of the correct times to use it - I'm sure there are other people it would help. I'd document it myself, but I don't want to spread more misinformation. I've guessed at what it does - I believe it's forcing a write to ZEO of the currently installed disk products running at the client side - but that's the nearest I could figure out. j.shell

2 2

error_log buggy?
by Joachim Werner 27 Sep '02

27 Sep '02

Hi! The UTF-8 errors I am getting because of the unicode problems in Zope 2.6b1 (see Collector issue 517) are not logged in the new error log, which means that there is no way of easily getting the traceback information AFAIK. Is that a feature or a bug? Joachim

2 1

RE: [Zope-dev] [ZOPE 2.6 B1] Unicode/locale problems with OFS/dtml/properties.dtml
by Arnar Lundesgaard 27 Sep '02

27 Sep '02

> what do you mean by "inserted into the form"? Put there by the dtml-method in a dtml-var statement. > That the response contains a single byte where you properties > contain character whose unicode value is greater than 127 ? Yes > how have you checked this? if so, thats a bug. In a Hex editor... The character 'æ' for instance is inserted as '0xE6' in the returned HTML. > > Secondly, the type attribute of all inputfields contain an extra > > ':utf8:' that we assumed is a server directive to interpret the > > contents as UTF-8. This apperently what crashes when storing the > > second time. > > This is a directive to tell zope when you submit the form > that your browser will have encoded the form response using > utf-8. Browsers stupidly dont put this information anywhere > more suitable. Yeah, we figured this would be similar to ':method'. > What browser are you using? is it correctly using utf8 for > this page? (for example, Mozilla has a View/Encoding menu > that can override server-supplied encoding information) We have so far tried Opera 6, IE 6 and Mozilla 1.1. > > lib/python/OFS/dtml/properties.dtml contains the following > > that seems to us to be debug code: > > <dtml-call "REQUEST.set('management_page_charset','UTF-8')"> > > <dtml-var "u''"> > > and several ':utf8:' directives. > > > > When we removed those, it worked fine. Was this dtml-method > > merged in mistakenly > > Those are supposed to be there. The first inserts the > text/html;charset=utf-8 header into the management page. > The second ensures that the dtml which computes this page > content returns a unicode object. > > If the dtml returns a unicode object, then ZPublisher looks > at the charset header to determine how to encode it. This is DTML/ZOPE internal, right? I though the first two letters to signify endianness 'FFFE' or 'FEFF', tells you that this is UTF-8. The u'' string is not on the firs line. > please put ib/python/OFS/dtml/properties.dtml back the way is > was originally, then send me > > 1. which browser you are using I am using Opera 6.02, but we are seeing it on all browsers. > 2. a export file containing one object that demonstrates the problem. It is on every property page in the whole site, but see the attached .zexp of /standard_template.pt > 3. a copy of the page obtained using wget or similar. > (please dont use your browsers 'save' feature because > that sometimes performs transcoding) I used wget... -- Arnar Lundesgaard

4 10

In 'unindex_object': path is an OOSet, not a string
by Jean Jordaan 27 Sep '02

27 Sep '02

Hi all I'm getting an error when calling 'unindex_object':: Error Type: AttributeError Error Value: split File /usr/local/zope/2-5-1/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py, line 151, in unindex_object (Object: path) From .../zope/2-5-1/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py :: def unindex_object(self,documentId): """ hook for (Z)Catalog """ if not self._unindex.has_key(documentId): return path = self._unindex[documentId] comps = path.split('/') At the point when 'comps = path.split('/')' is called, the value of 'path' is: OOSet([('Reminders', 0)]) This does not look as though it was ever supposed to happen. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za

2 2

Re: [Zope-dev] [ZOPE 2.6 B1] Unicode/locale problems with OFS/dtml/properties.dtml
by Joachim Werner 27 Sep '02

27 Sep '02

Hi! I have tracked down the problem with Collector issue 517 (Unicode problems) now: My Product used a modified manage_page_header that did not set the meta header for the encoding. After copying the relevant lines from the new manage_page_header in Zope 2.6 everything works fine, except for one remaining issue: One can create properties with Umlauts or other non-ASCII characters (which probably should be forbidden in general). While in 2.5.1 it is possible to delete such properties again, 2.6b1 will throw an error: The property [...] does not exist Probably the lookup in the property dictionary does not use the right encoding. I am not sure if that breaks old code, but the best way of getting rid of that problem might be to catch the creation of non-ASCII property names and don't let people use them. Cheers Joachim

2 1

[ZOPE 2.6 B1] Unicode/locale problems with OFS/dtml/properties.dtml
by Arnar Lundesgaard 27 Sep '02

27 Sep '02

We are trying out 2.6 b1. So far it seems very snappy (!!), and the new error-log object is exceptionally usefull! Kudos to Zope Corp and the community. :-) While trying the beta we have found a few problems in the handling of propertysheets. We can successfully store Norwegian characters ('æ','ø', and 'å') in property fields, but when we reload the page, we get results that display wrong. When studying the generated sources, we see that the data from ZOPE inserted into the form is ISO-8859-1. OTOH this field is inserted in the html-header: <meta http-equiv="content-type" content="text/html;charset=UTF-8"> Therefore the browser tries to display utf-8, which of course becomes garbage when you get an ISO-8859-1 character with a larger value than 127. All other pages (than the "properies" tab) in the have <meta http-equiv="content-type" content="text/html;charset=ISO-8859-1"> Secondly, the type attribute of all inputfields contain an extra ':utf8:' that we assumed is a server directive to interpret the contents as UTF-8. This apperently what crashes when storing the second time. lib/python/OFS/dtml/properties.dtml contains the following that seems to us to be debug code: <dtml-call "REQUEST.set('management_page_charset','UTF-8')"> <dtml-var "u''"> and several ':utf8:' directives. When we removed those, it worked fine. Was this dtml-method merged in mistakenly, or are there problems in our setup. Arnar Lundesgaard ------------------------------------------------------- phone: (+47) 982 38 036 mailto:arnar.lundesgaard(at)creuna.no Creuna as Bryggegata 3 NO-0250 Oslo phone office: (+47) 23 23 88 00 fax: (+47) 23 23 88 50 http://www.creuna.no/

3 2

B0rked my ZODB?
by Sidnei da Silva 26 Sep '02

26 Sep '02

I was happily trying to startup my Zope2.6 instance, running from the Zope-2_6-branch with an ZODB copied from a 2.5 insance and got the following error: 2002-09-26T18:20:07 PANIC(300) z2 Startup exception Traceback (innermost last): Module __main__, line 570, in ? Module <string>, line 1, in ? Module Zope, line 75, in ? Module OFS.Application, line 342, in initialize Module ZODB.Transaction, line 223, in commit Module ZODB.Transaction, line 195, in commit Module ZODB.Transaction, line 257, in _commit_objects Module ZODB.Connection, line 402, in commit - __traceback_info__: (('Persistence', 'PersistentMapping'), '\x00\x00\x00\x00\x00\x00\x00\x00', '') TypeError: object of type 'list' is not callable Is this something that changed on the last days? It was working with a CVS checkout from 2 days before the 2.6Beta1 release. []'s -- Sidnei da Silva (dreamcatcher) <sidnei(a)x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18 ppc Those who don't understand Linux are doomed to reinvent it, poorly. -- unidentified source

2 2

Is the aliasing of 'hasRole' correct?
by Jean Jordaan 26 Sep '02

26 Sep '02

In AccessControl/User.py:: def hasRole(self, *args, **kw): """hasRole is an alias for 'allowed' and has been deprecated. Code still using this method should convert to either 'has_role' or 'allowed', depending on the intended behaviour. """ import warnings warnings.warn('BasicUser.hasRole is deprecated, please use ' 'BasicUser.allowed instead; hasRole was an alias for allowed, but ' 'you may have ment to use has_role.', DeprecationWarning) self.allowed(*args, **kw) Shouldn't that be:: return self.allowed(*args, **kw) ? -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za

2 1

Unicode Diffs
by kent sin 26 Sep '02

26 Sep '02

I have a quick hack of Zope to use utf-8 as default encoding. This will allow all languages co-exist, making a heaven for different language users. Also, this help to easy Zope 2.6 for non latin users. I did not test this very throughly, but it seems not broken any thing yet. Please consider seriously make this into zope 2.6. I know this is very late, but the current 2.6 is very bad to non-latin users. Rgs, Kent Sin __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

5 4

Re: AW: [Zope-dev] Access problem.
by Ignacio Dosil Lago 26 Sep '02

26 Sep '02

On Wednesday 25 September 2002 20:34, you wrote: > > -- I am developing a CMF "link" product which defines its own traverse > > method: > > > > def __bobo_traverse__(self, request, name=None): > > "Traverse method hook" > > > > if hasattr(self, name): > > # return own attributes/subobjects > > return getattr(self, name) > > else: > > t= self.getTarget() > > if hasattr(t, name): > > # return target's attributes/subobjects > > return getattr(t, name) > > else: > > return t > > > > -- It works fine under the ZMI but when I try to access an object of this > > product into a CMF portal using the CMF interface, Zope requests me login > > name and password (even if I am admin!!), which it doesn't accept, so the > > only way to continue is to cancel instead of triying to log in. > > I had a similar problem when accessing the request object in > __bobo_traverse__(self, request, name). Authentication didn´t work > afterwards. > I don´t what happens in getTarget() but maybe that´s the problem. > Arndt I don't thing the poblem is in getTarget() because when the exception is thrown that method is never called. The exception is thrown when "__bobo_traverse__" returns "getattr(linkObject, 'portal_url')" and only when we are working with links in the CMF interface, not the ZMI. Any suggestions/questions? Kind regards.

1 0