[Zope-dev] Success at porting ZTK to Python 3!
Subject: Success at porting ZTK app to Python 3! Hi all, I'm glad to announce that we at CipherHealth have recently ported a full-fledged ZTK application to Python 3! What is cipher.uibuilder? ~ UI Builder is the infrastructural part of our major product. It is a library for building multi-tenant systems for business applications that involve import, processing and export of some data. UI Builder allows the admin to set up various user-facing views for the data, including tables, forms, charts, etc. Each tenant (site) has a separate configuration that is editable TTW and is stored using the ZODB and ConfigParser files on disk. The configuration files then can be loaded into a site. This allows us to version configurations and move them between environments. UI Builder also provides facilities for scheduled tasks and background execution of long-running jobs using celery. UI Builder uses z3c.form, z3c.table, as well as zope.publisher and friends. We have put together a simple demo application that exercises most UI Builder features. Status of the Python 3 port ~~~ We have the demo application successfully running on Python 3.3. In order to do that we have to rely on a number of alpha packages and several unreleased versions in py3 branches of dependencies. There still are several open issues, such as absence of xlwt-based Excel output and the issue of ZODB data backwards compatibility. In order to get zope.testbrowser-based tests to work on Python 3, we chose to migrate to WebTest as the back end instead of mechanize, as mechanize proved to be too hard to port to Python 3. The new version of zope.testbrowser is highly compatible with the previous one, verified on test suites of several major applications which used zope.testbrowser. Trying it out ~ If you're interested, you can check out the py3 branch of cipher.uibuilderdemo. Follow the instructions in the README.txt: https://github.com/CipherHealth/cipher.uibuilderdemo/tree/py3 Albertas ___ 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 )
[Zope-dev] zope.security and Python 3
Hi, While porting one ZTK app to Python 3 I discovered the following problems with zope.security: 1) There was a package zope.app.security, which, along with zope.app baggage provided security declarations for BTrees and PersistentDict, PersistentList. They were in a separate file, _protections.zcml. What would be a good place for these from now on? zope.security? There is also a file globalmodules.zcml in zope.app.security, which declares public APIs of a lot of standard library modules. These declarations don't seem to enable open access on attributes of those classes, though. Is that a leftover of old untrusted TTW code attempts or does it do something useful? 2) PersistentDict on Py3 is based on collections.abc.Mapping, which uses classes such as collections.abc.View, KeysView, ValuesView for the results of the relevant methods. These classes currently have no security declarations. Perhaps all immutable/view classes in collections.abc should be added to the list of basic types in zope.security.checker? Or just declared together with persistent and BTrees classes? For Python 2 we can hedge out the declarations with zcml:condition=not-installed collections.abc. 3) BTrees have problems with security, too. Their items/keys/values methods return objects of classes like OOBTreeItems. On Python 2 zope.security used to pass them through, on Python 3 I'm getting ForbiddenAttribute errors. These classes don't seem importable, so it's not obvious how to declare their permissions. Thoughts? Advice? Albertas ___ 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] cache_detail crash
On Thu, Sep 22, 2011 at 12:59:43PM +0400, Ruslan Mahmatkhanov wrote:
Ok, this change works for me.
It should be applied against src/App/CacheManager.py.
Would you mind to commit it?
REQUEST.RESPONSE.setHeader('Content-Type', 'text/plain')
-return '\n'.join('%6d %s'%(count, name) for count, name in
detail)
+return '\n'.join('%s %6d'%(count, name) for count, name in
detail)
This doesn't look right! So count is %s, and name is %d? Perhaps
their order in detail changed?
Albertas
___
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] Survey: most obscure errors
On Tue, Sep 14, 2010 at 12:00:58PM +0200, Marius Gedminas wrote: What are the most obscure error conditions you've encountered while developing Zopeish[1] applications? Trying to add a proxied object to the database gives an error that more or less clearly states this condition (proxies are unpickleable). Nevertheless, it might be confusing to newbies, and it does not give any clues about the place that caused the error, not even what was the proxied object. Albertas ___ 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 )
[Zope-dev] Path expression traversal in z3c.pt
Hi,
I tried switching to z3c.pt in one of our projects and found an
incompatibility with zope.app.pagetemplate. It is not obvious whether
it is a bug or a feature, so I thought I should bring it up here.
Here is a doctest illustrating the incompatibility.
First, let's set up both types of templates:
from zope.pagetemplate.pagetemplate import PageTemplate
from zope.app.pagetemplate.engine import TrustedAppPT
class ZopePageTemplate(TrustedAppPT, PageTemplate):
... def __init__(self, source):
... self.pt_edit(source, '')
from z3c.pt.pagetemplate import PageTemplate as Z3CPageTemplate
from z3c.pt.expressions import path_translator
from zope.component import provideUtility
provideUtility(path_translator, name=path)
Normally, traversing in path expressions prefers attributes over
items, but makes an exception for dict objects.
arg = {'copy': 1}
ZopePageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
u'p1/p\n'
Z3CPageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
u'p1/p'
However, attribute lookup takes precedence for other dict-like objects:
from UserDict import UserDict
arg = UserDict()
arg['copy'] = '1'
ZopePageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
up{'copy': '1'}/p\n
Z3CPageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
up{'copy': '1'}/p
However, Zope lets the user override this behaviour by providing a
traversing adapter:
from zope.traversing.interfaces import ITraversable
from zope.interface import implements
class MyDict(UserDict):
... implements(ITraversable)
... def traverse(self, name, path):
... return self[name]
arg = MyDict()
arg['copy'] = '1'
ZopePageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
u'p1/p\n'
Z3CPageTemplate(p tal:content='options/arg/copy'/)(arg=arg)
up{'copy': '1'}/p
Here the behaviour diverges, as
zope.app.pagetemplates.engine.ZopeTraverser looks for an ITraversable
adapter and gets DefaultTraversable to implement the default
behaviour, whereas z3c.pt.expressions.ZopeTraverser tries the
attribute lookup before looking up the adapter.
To summarize, z3c.pt prefers attribute lookup to traversable adapters,
whereas zope.app.pagetemplate doesn't.
Is this divergence a bug or a feature? Anyhow, it should be either
unified or documented.
Albertas
--
http://pov.lt -- ZTK/BlueBream consulting and development
___
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] Developer meeting 2010-07-27 at 15:00 UTC
On Wed, Jul 28, 2010 at 10:12:14AM +0200, Vincent Fretin wrote: - Zope Components for the Win, Albertas Agejevas My slides are available here: http://fridge.pov.lt/~alga/ep2010/ep2010-agejevas.html Albertas ___ 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] New Zope 3 name: BlueBream
On Tue, Jan 05, 2010 at 09:29:10AM -0500, Stephan Richter wrote: On Monday 04 January 2010, Baiju M wrote: I am proposing to call Zope 3 - the web frame work as BlueBream. The main use for name is documentation. But the package named bluebream will not provide any part of framework code by itself. All the framework code will be in zope and zope.app namespaces. I like the name too. As Simon suggested, a shorter Bream might be better. There is too much blue in technology already.. +1, and I'm also a Zope 3 programmer. Albertas ___ 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] zope.catalog in ZTK
On Tue, Sep 29, 2009 at 01:09:08PM +0200, Martijn Faassen wrote: About a year ago zope.app.catalog as been moved to zope.catalog. I think during this move there was a unique opportunity to leave these event handlers behind in zope.app.catalog, so that the no .app version is free of these forced choices. Doing this would have needed a migration strategy more complicated than Oh, I'm just going to lose the ZMI when I switch and people's applications somehow would have to gain registrations manually. I guess a damn good changelog would've helped somewhat.. Correct me if I'm wrong, but zope.app.catalog still remains with the ZMI bits and re-imports of the zope.catalog functionality. So apps depending on zope.app.catalog are not affected at all. I'm saying that some of the event handlers (or their ZCML registrations) could have stayed there as well. But perhaps it's not too late to do in now? After all, no stable version of Zope 3 / ZTK codebase has been released after this move? People relying on automatic indexing would have to register a couple of event handlers in their configurations (or include zope.app.catalog), but the rest of us would be able to choose the policy of how and when the objects are registered with IntIds and indexed in the catalog. Would you propose the same treatment for zope.intid as well? I don't know, the subscribers in zope.intid don't bother me too much. Would this involve removing the configure.zcml in these packages, or what is your proposal exactly? In essence, I would like to see zope/catalog/subscribers.zcml removed from the default zope/catalog/configure.zcml. Again, it needs damn good documentation if we were to go ahead with this, including details on how to register event handlers to accomplish the previous behavior. Both the changelog and the documentation that appears on pypi would need to be updated with instructions about what is going on. This change would also definitely be worth a feature release. +1 if documentation is good. :D Albertas ___ 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] zope.catalog in ZTK
On Tue, Sep 29, 2009 at 01:33:21PM +0200, Hanno Schlichting wrote: Is there any reason you don't just ignore the configure.zcml in that package? Nobody forces you to load the zcml file. The whole point of having these policies in zcml is to be able to ignore or override them easily. Good point, thanks! I haven't looked at the configure.zcml for zope.catalog previously. In fact the config for zope.catalog is split into several files, so it's very easy to leave out the subscribers but include the rest. Albertas ___ 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 )
[Zope-dev] zope.catalog in ZTK
Hi all, zope.catalog is a crucial part of ZTK, as it adds the equivalent of RDBMS SELECT queries to our ODB based apps. However in my opinion its default setup is suboptimal as a generic library in ZTK, because it is hardwired up for ZMI point and click operation. As soon as you create and register an ICatalog utility, every ObjectAddedEvent and ObjectModifiedEvent will trigger stuffing the object into intids, and each intid registration event will trigger an attempt to index an object. When you add an index to the catalog, it gets reindexed automatically. Because these behaviours are implemented by event handlers, there is no way for an app to override or disable them. There is an opt out mechanism for keeping objects out of the catalog (INoAutoIndex, INoAutoReindex marker interfaces), but curiously the latter does not inherit from the former,so your object can be indexed on modification even if you made it provide INoAutoIndex. Automatically stuffing all newly added objects into the int ids utility and then further into the catalog is bad, because, first, it cripples any alternative uses of the int ids utility, turns it into purely a catalog accessory, and second, places some restrictions on containers and contained objects due to the persistent oid based key reference implementation. About a year ago zope.app.catalog as been moved to zope.catalog. I think during this move there was a unique opportunity to leave these event handlers behind in zope.app.catalog, so that the no .app version is free of these forced choices. But perhaps it's not too late to do in now? After all, no stable version of Zope 3 / ZTK codebase has been released after this move? People relying on automatic indexing would have to register a couple of event handlers in their configurations (or include zope.app.catalog), but the rest of us would be able to choose the policy of how and when the objects are registered with IntIds and indexed in the catalog. Albertas -- http://www.pov.lt/ -- Zope and Python consulting ___ 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] Defining Zope 3.
On Sat, Apr 18, 2009 at 08:32:52AM -0600, Shane Hathaway wrote: Given that definition, Zope Toolkit will start relatively small, since much of Zope 3 does not yet qualify. However, as people refine packages, the packages will be reconsidered for inclusion in the Zope Toolkit, and the Zope Toolkit will hopefully grow into something similar to what we currently know as Zope 3. Zope 3 can't die; people are relying on it and maintaining it. The maintainers are doing a rather good job too, IMHO. The checkins list has been active lately. We don't have to create any more Zope 3 tarballs, but we should keep up the KGS. The Zope Toolkit will be the subset that's good for building applications, web sites, and frameworks. Zope 3 will be designed only for building applications and web sites. +1, this sounds like a good way forward. Albertas ___ 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 )
