- Zope-Dev - Zope lists

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

Re: __contains__ and acquisition problem?
by Florent Guillaume 02 Jun '06

02 Jun '06

Ok I fixed this for Zope 2.10 and trunk: http://svn.zope.org/?view=rev&rev=68459 Florent Jim Fulton wrote: > Anyway, the acquisition wrapper implementation hasn't been updated to > handle > many slots that were added in recent years, including __contains__. > > Jim > >> Florent Guillaume wrote: >> >>> Could anybody shed some light on what's happening here: >>> >>> >>> from Acquisition import Implicit >>> >>> >>> class Impl(Implicit): >>> ... pass >>> >>> >>> class C(Implicit): >>> ... def __getitem__(self, key): >>> ... print 'getitem', key >>> ... if key == 4: >>> ... raise IndexError >>> ... return key >>> ... def __contains__(self, key): >>> ... print 'contains', repr(key) >>> ... return key == 5 >>> >>> The class by itself behaves as expected: >>> >>> >>> c = C() >>> >>> 5 in c >>> contains 5 >>> True >>> >>> 3 in c >>> contains 3 >>> False >>> >>> Let's put c in the context of i: >>> >>> >>> i = Impl() >>> >>> i.c = c >>> >>> Now why is the following happening? Why is __contains__ not used? >>> >>> >>> 3 in i.c # c.__of__(i) >>> getitem 0 >>> getitem 1 >>> getitem 2 >>> getitem 3 >>> True >>> >>> 5 in i.c >>> getitem 0 >>> getitem 1 >>> getitem 2 >>> getitem 3 >>> getitem 4 >>> False >>> >> >> > > -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

1 0

Re: SVN: Zope/trunk/lib/python/AccessControl/ Make python security policy work with a boolean __aatus__
by Philipp von Weitershausen 01 Jun '06

01 Jun '06

Florent Guillaume wrote: > Log message for revision 68446: > Make python security policy work with a boolean __aatus__ Wow, I wasn't aware that only ints were possible. Shouldn't this be backported to Zope 2.9 as well? I consider it a bug when an 1 won't be exchangeable for True in something that's apparently either true of false. By the way, a test for isinstance(__aatus__, int) would also be true for booleans because bool inherits from int. Philipp

2 3

Zope 2.10 TALES repeat and 'item'
by Florent Guillaume 01 Jun '06

01 Jun '06

The following TALES expression using the 'item' name doesn't work: python:repeat['item'].even() Unauthorized: The container has no security assertions. Access to 'even' of (Products.PageTemplates.Expressions.PathIterator object at 0x47986f0) denied. whereas this works: repeat/item/even Anyone knows why? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

2 2

Zope 2.10 deprecation warnings
by Florent Guillaume 01 Jun '06

01 Jun '06

Current bare Zope 2.10 sends some deprecation warnings because it itself imports things that it deprecates, this will have to be hidden. Suggestions welcome: - App/Product.py imports ZClasses which are deprecated, - Products/ZCatalog/ZCatalog.py imports TextIndex (for the Splitters) but TextIndex is deprecated. Also I've checked in a fix for the ZPT warnings such as: Init Ambiguous name for method of Products.PageTemplates.ZopePageTemplate.ZopePageTemplate: 'manage' != 'manage_main' Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

2 2

tempstorage to ZEO?
by Sidnei da Silva 01 Jun '06

01 Jun '06

I was looking, and trying to understand why 'tempstorage' is not included in the ZODB. Since some people might want to share sessions between ZEO clients, and that 'tempstorage' is what is mounted as '/temp_folder/session_data', why not make that easy to mount via ZEO? Does anyone see a problem with this? What I'm proposing is to move 'tempstorage' to 'ZODB', since it has no dependency on anything other than 'zLOG'. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

6 16

Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testZopePageTemplate.py A recent fix in the zope 3 traversing code now requires the ITraversable
by Tres Seaver 31 May '06

31 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Log message for revision 68328: > A recent fix in the zope 3 traversing code now requires the ITraversable > adapter to be present even when traversing just dicts. No problem, we can > set it up quite easily. > > This basically finishes this branch. All tests pass, some 3rd party apps > have been tested with it. There are a few test failures in the CMF and > others (e.g. Plone), but that's mostly "their fault" (incorrect or > unexpected usage of certain things). Those are BBB fouls, as those failures do not emit deprecation warnings when run against 2.9. In fact, none of the deprecation warnings which are raised when running the CMF 2.0 tests under 2.9 allow for failures under 2.10. The failrures are mostly instances of: - The "empty path element" exception. Zope3's choice to make that an error is undefended, AFAIK (Fred never replied to your query about the reason), and needs BBB in any case. - CMFDefault/skin/configure.zcml blows up because the syntax of the 'browser:skin' directive has changed in a BBB-incompatible way. The now-failing directive is:: <browser:skin name="cmf" layers="cmf default" /> and the traceback is *very* weird:: ZopeXMLConfigurationError: File \ "/tmp/endgame/Products/CMFDefault/skin/configure.zcml", line \ 10.2-13.8 ConfigurationError: ('Invalid value for', 'layers', "ImportError:\ Couldn't import default, No module named default in cmf default") - "No traversable adapter found" raised out of 'boboAwareZopeTraverse'. This one is likely due to the prior ZCML issue, which blows out ZCML processing early. These problems aren't blockers for a 2.10 beta, but they must be resolved before a final release. 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 iD8DBQFEelcj+gerLs4ltQ4RAqRcAJ0feXoFF2V19kS0VBRuwmW4BDkGFQCeM8Ta VRMWb2tyUuWSSzL1EtM80bk= =7/6v -----END PGP SIGNATURE-----

7 15

Re: SVN: Products.Five/trunk/ Five now requires site.zcml to live in /etc
by Tres Seaver 30 May '06

30 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rocky Burt wrote: > Log message for revision 68359: > Five now requires site.zcml to live in /etc > > Changed: > U Products.Five/trunk/CHANGES.txt > D Products.Five/trunk/skel/ > U Products.Five/trunk/zcml.py > > -=- > Modified: Products.Five/trunk/CHANGES.txt > =================================================================== > --- Products.Five/trunk/CHANGES.txt 2006-05-29 19:42:51 UTC (rev 68358) > +++ Products.Five/trunk/CHANGES.txt 2006-05-29 20:24:13 UTC (rev 68359) > @@ -8,6 +8,18 @@ > Restructuring > ------------- > > +* Zope 2.10+ now includes site.zcml as part of its instance creation > + skel directory. As a consequence Five now requires this file to exist > + in every instance. If upgrading a site from Zope 2.9 to 2.10, you will > + need to copy site.zcml and package-includes/ from your installed Zope > + installation location (skel/etc/) into the etc/ directory of your upgraded > + instance. > + > + The rationale for requiring this new file is to bring Zope 2 instances > + closer in consistency to Zope 3 instances. It also eases use of Zope 3 > + coding techniques in Zope 2 and removes some confusion when trying > + to run pure Zope 3 applications on Zope 2. This is a BBB foul. The appropriate way to make such a change is to add a deprecation warning, leaveing the "old" behavior (which was to use the 'site.zcml' from inside Five) in place. Making "forward compatibility" smoother is *less* important than preserving "backward compatibility". 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 iD8DBQFEfHlq+gerLs4ltQ4RAlNbAJ9IISl/plYHaMXb7DuEEEvVMJu9pwCeMASk R/kuYOm5U9F03unBpcApm58= =hehK -----END PGP SIGNATURE-----

3 2