Zope-Dev June 2006

zope-dev@zope.dev

31 participants
55 discussions

Non-Latin-1 properties
by Yves Bastide 08 Jun '06

08 Jun '06

Hi! Sorry to beat a dead horse: the ZMI doesn't allow using non-Latin-1 properties. * properties are stored using the default-zpublisher-encoding (iso-8859-15); * manage_propertiesForm is input--output'ed using management_page_charset (UTF-8) ... * ... but built using join_unicode, which calls PyUnicode_DecodeLatin1. To see the problem: * with the default default-zpublisher-encoding (Latin-9), - set a property's value to '€' (not in Latin-1) - Save Changes: it will be displayed as '¤' (the corresponding character) - Save Changes again: 'charmap' codec can't encode character u'\xa4' in position 0: character maps to <undefined> (because '¤' is not in (Latin-9). * with default-zpublisher-encoding set to UTF-8 - set a property's value to '€' - Save Changes: it will be displayed as 'â¬' - Save Changes again: it becomes 'Ã¢ÂÂ¬' Note that this has repercussions not only on the ZMI but on other products, such as GenericSetup. Some possible fixes: * do nothing. This will please those wishing to deprecate the ZMI, but not the rest of us :-) * rewrite properties.dtml as a ZPT? * change join_unicode to use either default-zpublisher-encoding or yet another setting (which would default to Latin-1 to stay compatible)? Flames, comments? Thanks! Yves

3 5

zope2 requests VS zope3 requests
by Rocky Burt 07 Jun '06

07 Jun '06

Hi all, After trying to get zope3-style locale information from a zope2 request for another task today I discovered I had no idea what the plan was regarding uniting these two request models in short-term or long-term (or even if there are any plans). I've heard rumours that ultimately the preferred manner of integration of z2 and z3 requests was to replace the z2 ZPublisher with the z3 zope.publisher. Perhaps those are just rumours, I have no idea. In any event, that would certainly be long-term. But are we doing anything in the short-term? My naive idea was that perhaps we should start building FrankenHTTPRequest which extended the original ZPublisher HTTPRequest but then also implemented zope.publisher's IHTTPRequest interface. This would give us a fairly safe combination of both requests and enable more zope3 applications to work as-is on Zope 2 (the one example that comes to mind is zope3's formlib which requires locale information to be present on the active request based on zope.publisher's IHTTPRequest). To be honest I'm only throwing random ideas out here just to spark a discussion. Maybe you all have already figured out the appropriate game plan. Either way, I'd just like to know :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net

5 6

Unittests with different zope configuration?
by Andreas Jung 07 Jun '06

07 Jun '06

Does anyone know how to write unittests that have to deal with different configurations in zope.conf? In my particular case I need write some tests for sequence.sort() that deal with the 'locale' configuration in zope.conf. So how do I setup a different configurations in a unit test? Andreas

4 7

zeo server conflict resolving
by M. Krainer 06 Jun '06

06 Jun '06

Can someone please enlighten me on conflict resolving of the zeo server? I'm getting occasional conflict errors from the zeo server. The class I'm getting those conflict errors is a simple class (only inheriting from Persistent) that defines a _p_resolveConflict() method. What I found out so far is, that in FileStorage.store() if serial!=cached_tid then tryToResolveConflict() gets called. In this method, in order to resolve the conflict, find_globals tries to import the module where my class is defined. Here's the problem. The zeo server has no information about my Products dir. I added it to the PYTHONPATH variable in zeoctl before starting the server. If I do a 'zeoctl show python' the Product dir shows up in the path, but when I log sys.path from within the find_globals() method it does NOT show up. How can I teach the zeo server to lookup my Products dir to resolve the conflict? - Markus

4 6

Re: [Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/ Merged r68461 from 2.10 branch:
by Chris Withers 05 Jun '06

05 Jun '06

Out of interst, why not just make this change wherever empty tales expreessions have been used in the past? It'd be clearer as to what the intention was and remove the necessity for hacky code like this... cheers, Chris Florent Guillaume wrote: > Log message for revision 68462: > Merged r68461 from 2.10 branch: > Empty TALES path expressions are allowed in Zope 2. > http://www.zope.org/Collectors/Zope/2118 > > > Changed: > U Zope/trunk/lib/python/Products/PageTemplates/Expressions.py > U Zope/trunk/lib/python/Products/PageTemplates/tests/testExpressions.py > > -=- > Modified: Zope/trunk/lib/python/Products/PageTemplates/Expressions.py > =================================================================== > --- Zope/trunk/lib/python/Products/PageTemplates/Expressions.py 2006-06-02 15:02:15 UTC (rev 68461) > +++ Zope/trunk/lib/python/Products/PageTemplates/Expressions.py 2006-06-02 15:04:12 UTC (rev 68462) > @@ -99,6 +99,8 @@ > class ZopePathExpr(PathExpr): > > def __init__(self, name, expr, engine): > + if not expr.strip(): > + expr = 'nothing' > super(ZopePathExpr, self).__init__(name, expr, engine, > boboAwareZopeTraverse) > > > Modified: Zope/trunk/lib/python/Products/PageTemplates/tests/testExpressions.py > =================================================================== > --- Zope/trunk/lib/python/Products/PageTemplates/tests/testExpressions.py 2006-06-02 15:02:15 UTC (rev 68461) > +++ Zope/trunk/lib/python/Products/PageTemplates/tests/testExpressions.py 2006-06-02 15:04:12 UTC (rev 68462) > @@ -86,6 +86,15 @@ > self.failUnless(isinstance(defer, DeferWrapper)) > self.failUnless(isinstance(lazy, LazyWrapper)) > > + def test_empty_ZopePathExpr(self): > + """Test empty path expressions. > + """ > + ec = self.ec > + self.assertEquals(ec.evaluate('path:'), None) > + self.assertEquals(ec.evaluate('path: '), None) > + self.assertEquals(ec.evaluate(''), None) > + self.assertEquals(ec.evaluate(' \n'), None) > + > def test_suite(): > return unittest.makeSuite(ExpressionTests) > > > _______________________________________________ > Zope-Checkins maillist - Zope-Checkins(a)zope.org > http://mail.zope.org/mailman/listinfo/zope-checkins > -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 1

Bugday for Zope 2.10?
by Andreas Jung 04 Jun '06

04 Jun '06

Hi everyone, I propose to have a bugday before the next Zope 2.10 beta release. How about June, 15th? Andreas

2 1

Re: SVN: CMF/branches/1.6/ - preparing CMF 1.6.1-beta
by Florent Guillaume 03 Jun '06

03 Jun '06

On 3 Jun 2006, at 20:46, Jens Vagelpohl wrote: > On 3 Jun 2006, at 18:49, Florent Guillaume wrote: >> I didn't see the GenericSetup checkin creating that tag, could you >> check that you're subscribed (but not receiving mail if you don't >> want to) to the list >> http://mail.zope.org/mailman/listinfo/zope-cvs >> Or are these checkins messages now going somewhere else? > > I am subscribed to the checkins(a)zope.org list and everything shows > up on it. Are you on that list? I am, but not reading mail through it, I'm using Gmane. It seems checkins(a)zope.org is not on Gmane. Should I ask for it to be added? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

2 1

default view
by Florent Guillaume 03 Jun '06

03 Jun '06

In current Zope 2.10, when you have: <page name="thepage" for=".IFoo" class=".view.FooView" attribute="thepage" permission="zope2.View" /> and a URL like: http://.../foodoc/thepage it seems that the publisher will still use attribute lookup (and therefore acquisition) before the view if you have a URL like This is unfortunate because in my case I want to use a page name that is present as an attribute on all the parents ("view", this is for CMF), and there seems to be no way of having the Five views take precedence over attributes and acquisition. What's the reason for having decided to do it this way? Can this be changed? A second problem is that even if I specify: <browser:defaultView name="thepage" for=".IFoo" /> and the URL: http://.../foodoc/ then "thepage" is still looked up as above, attribute lookup first. I'm pretty that in this cas we only want view lookup. Opinions? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

1 0

Lazy expressions appear to cause memory leaks
by Geoff Davis 02 Jun '06

02 Jun '06

In Zope 2.8+ there is a little known but very useful TALES feature: you can have expressions be lazily evaluated. For example, <span tal:define="foo lazy:python:someExpensiveMethod()" /> The "lazy:" prefix causes the python expression to not be evaluated until foo is used somewhere. There appears to be a fairly big problem with this setup. The lazy: prefix wraps the expression in a LazyExpr which stores the expression and its context. The LazyExpr in turn generates a LazyWrapper (that holds similar information) which ends up getting held in the TALInterpreter's global/local variable list. The expression context for TAL expressions in a page template includes things like the template itself, the context object (a fully wrapped object), the request (chock full of complicated stuff), and so on. It appears that storing the expression context in the lazy wrapper creates some kind of circular reference or something similar that is preventing garbage collection of these lazy wrappers. The result is a nasty memory leak. The problem appears to be fixable via some cleaning up in PageTemplate.pt_render after the interpreter does its thing. The code snippet below is probably overkill, but something like this appears to be what is needed: context = getEngine().getContext(c) TALInterpreter(self._v_program, self._v_macros, context, output, tal=not source, strictinsert=0)() # clean up - try to eliminate circular references - this may be overkill context._compiler = None context.contexts = None context.repeat_vars = None from Products.PageTemplates.DeferExpr import LazyWrapper for k,v in context.global_vars.items(): if isinstance(v, LazyWrapper): v._expr = None v._econtext = None v._result = None if context.vars: while len(context.vars): context.vars._pop() context.global_vars.clear() context.global_vars = None context.local_vars.clear() context.local_vars = None context.vars = None context._scope_stack = None

1 0

Re: SVN: Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py Revert unwanted checkin.
by Tres Seaver 02 Jun '06

02 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Guillaume wrote: > Log message for revision 68445: > Revert unwanted checkin. > > > Changed: > U Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py > > -=- > Modified: Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py > =================================================================== > --- Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 2006-06-01 14:44:13 UTC (rev 68444) > +++ Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 2006-06-01 14:46:17 UTC (rev 68445) > @@ -99,8 +99,6 @@ > class ZopePathExpr(PathExpr): > > def __init__(self, name, expr, engine): > - if name == 'standard' and not expr: > - expr = 'nothing' > super(ZopePathExpr, self).__init__(name, expr, engine, > boboAwareZopeTraverse) Why revert? I was fine with this, rather than my warning-emitting version. Go ahead and forward-port it to the trunk, and close out the collector issue with a note saying "Zope2 allows empty path expressions" (maybe reference the issue in the code?) Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfy7B+gerLs4ltQ4RApyTAKCmDBSKHNAuG3eTUH1Z/tLH59fKDQCgzT8X paaBvzwGUbuOhP5bB2kuRoA= =mIGe -----END PGP SIGNATURE-----

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev June 2006