[Zope-dev] Re: New Contributor References
On 2007-09-12 15:32:42 +0200, Jim Fulton [EMAIL PROTECTED] said: Lately, I've started being a bit more careful about accepting new contributors. In particular, I'm requesting that new contributors provide the name of an existing contributor who is familiar with them and their work. I (or someone) really need to add this to the contributor agreement, but I'm not sure when I'll have time. Now, It's taking a fair bit of time writing new contributors to ask for references. I encourage folks to request committer access, I just ask that people provide the names of one or more existing committers who can vouch for them. I think that is good. It's just like noting references on a job application. Sobody you (as employer) can call/mail and ask about the applicant. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
Hi, a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise: * Skin and layers should be seen as typing the request. * There are no general objections against having layers for XML-RPC. * There are objections against using ++skin++ for XML-RPC, ++api++ would be fine. Discussing the issue here at gocept again we've come to the following: There are different kinds of request (BrowserRequest, XMLRPCRequest, FTPRequest, …) which depend on the “channel” or server zope is accessed through. Then, depending on the kind of request, it often is desirable to further type the request: * a skin for browser requests * an API for xmlrpc requests * maybe different listings or content views for webdav We’d like to codify this understanding (the general concept of marking a request with a type) using a general IRequestType which all specific type implementations (skins, APIs, ...) are derived from. In our view this allows for understandably named implementations for each channel but still provide a common base. Therefore we propose to: * Create in zope.publisher.interfaces: class IRequestType(zope.interface.interfaces.IInterface): pass * Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a traverser ++api++ for IXMLRPCApiType. * Use IRequestType as new base of IBrowserSkinType (instead of IInterface). * Do *not* provide any traverser for IRequestType since the traversers should be close to the “channel” so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc. Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Should zope.annotation.factory send ObjectAddedEvent?
Hi, zope.annotation.factory is a very handy tool. I wonder if it should not send an ObjectAddedEvent when the annotation object is created. After all an object is added. But there is no (easy) way catalog those objects or do anything. If there are no objections I'll add this. Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: Should zope.annotation.factory send ObjectAddedEvent?
On 2007-12-21 09:52:34 +0100, Christian Zagrodnick [EMAIL PROTECTED] said: Hi, zope.annotation.factory is a very handy tool. I wonder if it should not send an ObjectAddedEvent when the annotation object is created. After all an object is added. But there is no (easy) way catalog those objects or do anything. I have to correcty myself: ObjectAddedEvent is the wrong event I suppose since it is from zope.app.container and the annotation factory doesn't add it into a container. zope.lifecycleevent.ObjectCreatedEvent might be okay though. There should be at least some event when this object was created, shouldn't there? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] zope.viewlet 3.4.1 release broken
Hi, the release of zope.viewlet 3.4.1 on pypi is missing the data files (like .txt and .zcml), hence it is unusable. Also the date in the CHANGES is wrong (2007 should be 2008) Roger, it is good that you do releases, but could to please take take of making them proper? Unfortunately I cannot fix it since I don't have access to zope.viewlet, so somebody else please fix it (or give me access). BTW Roger, z3c.menu.simple has the same problem of missing data files. Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: zope.viewlet 3.4.1 release broken
On 2008-01-24 14:21:44 +0100, Christian Theune [EMAIL PROTECTED] said: Christian Zagrodnick schrieb: Hi, the release of zope.viewlet 3.4.1 on pypi is missing the data files (like .txt and .zcml), hence it is unusable. Also the date in the CHANGES is wrong (2007 should be 2008) Roger, it is good that you do releases, but could to please take take of making them proper? Unfortunately I cannot fix it since I don't have access to zope.viewlet, so somebody else please fix it (or give me access). You have now. Thanks, I just uploaded zope.viewlet 3.4.2. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: AW: zope.viewlet 3.4.1 release broken
On 2008-01-24 17:11:32 +0100, Roger Ineichen [EMAIL PROTECTED] said: Hi Christian Betreff: [Zope-dev] zope.viewlet 3.4.1 release broken Hi, the release of zope.viewlet 3.4.1 on pypi is missing the data files (like .txt and .zcml), hence it is unusable. Also the date in the CHANGES is wrong (2007 should be 2008) No it doesn't miss the data. Your linux is just not able to extract them. It works on windows box. Interesting. So still the package would be broken for most users. I'm using Mac OS btw. Roger, it is good that you do releases, but could to please take take of making them proper? Probably you know already. That's a (linux) bug in the python tar library. I did nothing wrong. It's just broken if you extract the files from the egg. on linux. Everything is build correct. Could you clearify why the package I built works then? That's the great mystery I suppose ;) -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: AW: zope.viewlet 3.4.1 release broken
On 2008-01-24 22:28:19 +0100, Marius Gedminas [EMAIL PROTECTED] said: On Thu, Jan 24, 2008 at 12:06:16PM -0500, Stephan Richter wrote: On Thursday 24 January 2008, Christian Zagrodnick wrote: Probably you know already. That's a (linux) bug in the python tar library. I did nothing wrong. It's just broken if you extract the files from the egg. on linux. Everything is build correct. Could you clearify why the package I built works then? That's the great mystery I suppose ;) =20 Because UNIX built packages work on UNIX and Windows. But Windows built= =20 packages only work on Windows. This email contains the explanation -- it's a bug in distutils/setuptools: http://mail.python.org/pipermail/distutils-sig/2007-September/008296.html Note that the latest setuptools release (setuptools 0.6c7) does NOT contain the fix. So let's hope there will be a release which fixes this soon. This is very disturbing. And meanwhile we should not make releases on windows, should we. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: zope.viewlet 3.4.1 release broken
On 2008-01-24 18:04:44 +0100, Stephan Richter [EMAIL PROTECTED] said: On Thursday 24 January 2008, Christian Zagrodnick wrote: the release of zope.viewlet 3.4.1 on pypi is missing the data files (like .txt and .zcml), hence it is unusable. Also the date in the CHANGES is wrong (2007 should be 2008) The fact that you noticed this problem this quickly tells me you are not using the KGS. I tend to reply to this tough luck. I will update the KGS as soon as I have re-released the packages. Jim has also given me already a new zope-dev directory already, so we can evolve a new, experimental KGS there. BTW, if you want to use a newer package than the KGS provides, you can always use the find-links option and point to the package in PyPI or PPIX directly. Most component packages do not use the KGS in their buildout, so I wasn't either. For production use we pin exact versions actually. Roger, it is good that you do releases, but could to please take take of making them proper? He did take the care. The problem is a Python bug as Martijn pointed out later. Yeah, actually I wondered how it would be possible to do it wrong ;) BTW Roger, z3c.menu.simple has the same problem of missing data files. Yes, there are a bunch of packages that have this problem. I am going to re-release them all. (In fact, I have already started.) Good. Thanks! -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: SVN: zc.resourcelibrary/branches/resources-bundles-branch/src/zc/resourcelibrary/ Implemented resource manager capable of bundling resources based on library intersection and resource c
Hi, when will this be merged to the trunk and released? Any plans for that? On 2008-02-05 20:37:28 +0100, Malthe Borch [EMAIL PROTECTED] said: Log message for revision 83553: Implemented resource manager capable of bundling resources based on library intersection and resource content digests. This is explained in detail in README.txt under the section Resource bundles. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: SVN: zc.resourcelibrary/branches/resources-bundles-branch/src/zc/resourcelibrary/ Implemented resource manager capable of bundling resources based on library intersection and resource c
On 2008-02-13 13:07:47 +0100, Malthe Borch [EMAIL PROTECTED] said: Christian Zagrodnick wrote: when will this be merged to the trunk and released? Any plans for that? I still need to hook up the resource bundle with the publisher. The implementation hasn't been tested in a browser yet. There might be caveats. I'll try and bring the branch into a fully working state. Cool. Sounds really useful :) -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: Mailinglists on Launchpad
On 2008-02-18 11:20:05 +0100, Christian Theune [EMAIL PROTECTED] said: Launchpad started the beta tests for their mailing list offers. A while ago we discussed this option for future hosting of the mailing lists. The current implementation has the restriction that the mailing lists can not be hosted using custom domains (@zope.org). IMHO when migrating mailing lists the addresses should not change. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: SVN: zc.recipe.filestorage/trunk/ Removed 'shared-blob-dir' from blobstorage section
Hi
On 2008-02-27 21:00:39 +0100, Nikolay Kim
[EMAIL PROTECTED] said:
Log message for revision 84351:
Removed 'shared-blob-dir' from blobstorage section
could you tell me why you've removed the shared-blob-dir option?
One could argue to remove the whole blob support from the recipe, but
just removing the shared option is not useful IMHO.
Changed:
U zc.recipe.filestorage/trunk/CHANGES.txt
U zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py
-=-
Modified: zc.recipe.filestorage/trunk/CHANGES.txt
===
--- zc.recipe.filestorage/trunk/CHANGES.txt 2008-02-27 19:49:55 UTC (rev
84350)
+++ zc.recipe.filestorage/trunk/CHANGES.txt 2008-02-27 20:00:37 UTC (rev
84351)
@@ -2,6 +2,12 @@
CHANGES
===
+1.1.0 (2008-??-??)
+--
+
+- Removed 'shared-blob-dir' from blobstorage section.
+
+
1.0.0 (2007-11-03)
--
Modified: zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py
===
---
zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py 2008-02-27
19:49:55 UTC (rev 84350)
+++
zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py 2008-02-27
20:00:37 UTC (rev 84351)
@@ -41,12 +41,10 @@
blob_dir = os.path.join(buildout['buildout']['directory'],
blob_dir)
options['blob-dir'] = blob_dir
-shared = options.get('shared-blob-dir', 'no')
options['zconfig'] = template % dict(
path=path,
-blob_dir=blob_dir,
-shared=shared)
+blob_dir=blob_dir)
def install(self):
if self.make_part:
@@ -70,7 +68,6 @@
zodb
blobstorage
blob-dir %(blob_dir)s
-shared-blob-dir %(shared)s
filestorage
path %(path)s
/filestorage
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
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 )
[Zope-dev] Test isolation problems starting with zope.app.publisher 3.5.0a3
Hi, starting with zope.app.publisher 3.5.0a3 I geht isolation problems with tests. When the second functional test layer is reached the menus are empty. I don't know why this is but I'm pretty sure ist has todo with the checkin below. On 2007-11-27 20:59:01 +0100, Juergen Kartnaller [EMAIL PROTECTED] said: Log message for revision 81993: make it possible to override menus: this was not possible because new interfaces where created any time a menu with the same name was created. Changed: U zope.app.publisher/trunk/CHANGES.txt U zope.app.publisher/trunk/src/zope/app/publisher/browser/menumeta.py U zope.app.publisher/trunk/src/zope/app/publisher/browser/tests/support.py U zope.app.publisher/trunk/src/zope/app/publisher/browser/tests/test_directives.py -=- Modified: zope.app.publisher/trunk/CHANGES.txt === --- zope.app.publisher/trunk/CHANGES.txt2007-11-27 19:57:29 UTC (rev 81992) +++ zope.app.publisher/trunk/CHANGES.txt2007-11-27 19:59:00 UTC (rev 81993) @@ -5,6 +5,12 @@ 3.5.0 (???) === +3.5.0a3 (2007-11-27) + + +- make it possible to override menus: this was not possible because new + interfaces where created any time a menu with the same name was created. + - Resolve ``ZopeSecurityPolicy`` deprecation warning. [] -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] zope.component.zcml _protectedFactory not protecting?
Hi, I'm a little confused by the permission attribute on the adapter statement. First of all, a principal not having the set permission still gets the adapter. That wouldn't be much of a problem if the adapter was securiy-proxied. The adapter is created with the _protectedFactory: def _protectedFactory(original_factory, checker): # This has to be named 'factory', aparently, so as not to confuse # apidoc :( def factory(*args): ob = original_factory(*args) try: ob.__Security_checker__ = checker except AttributeError: ob = Proxy(ob, checker) return ob factory.factory = original_factory return factory I wonder why the factory only creates a security proxy when it cannot assign __Security_checker__ to the adapter. I suppose this is intentional? Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: Setting the size of a zope.formlib's schema html input
On 2008-04-07 03:41:34 +0200, Marcelo de Moraes Serpa [EMAIL PROTECTED] said: Hello, This might sound lik a stupid question, but I couldn't find any simple solution or answer for this anywhere else, so hopefully someone in this list knows the answer. I'm using zope.formlib to generate a simple contact form. It is simple and effective. But the framework complicates for simple things such as setting the size of a textfield. I don't want all the textfields to be of the same size - I want that, depending on the field, the size of the html input will vary. And that's exactly what I couldn't do as of yet. Does anyone know how could I set the size of a textfield? Take this as example: Telefone = schema.TextLine(title=_(uTelefone para Contato), required=True) Is there an attribute like size or something? No, use CSS for layout. :) You could also use a custom widget which has a different size, but CSS might be the more correct separation. Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: testing a meta-egg
On 2008-04-04 14:22:06 +0200, Jim Fulton [EMAIL PROTECTED] said:
On Apr 4, 2008, at 7:14 AM, Adam GROSZER wrote:
Hello,
Is there a sane way (or recipe) out there that makes testing a
meta-eggs easier?
As I see now, I'll need to enter all dependent eggs as:
[test]
recipe = zc.recipe.testrunner
eggs = my-meta-egg [test]
dep-egg-1 [test]
dep-egg-2 [test]
...
zope.interface [??test??]
Seems like buildout knows which eggs should be there.
This would be needed for a pre-installation test on the target system.
We need to make sure that all tests pass before going into production.
Any help is appreciated.
IMO, testing the dependent eggs isn't desirable, however, I don't
object to providing an option to do it.
It might be better to just provide a variable containing all the
dependent eggs like ${test:dependent-eggs}. You could do what ever you
want then.
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
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 )
[Zope-dev] Re: Setting the size of a zope.formlib's schema html input
On 2008-04-07 09:25:28 +0200, Wichert Akkerman [EMAIL PROTECTED] said: Previously Christian Zagrodnick wrote: On 2008-04-07 03:41:34 +0200, Marcelo de Moraes Serpa [EMAIL PROTECTED] said: Hello, This might sound lik a stupid question, but I couldn't find any simple solution or answer for this anywhere else, so hopefully someone in this list knows the answer. I'm using zope.formlib to generate a simple contact form. It is simple and effective. But the framework complicates for simple things such as setting the size of a textfield. I don't want all the textfields to be of the same size - I want that, depending on the field, the size of the html input will vary. And that's exactly what I couldn't do as of yet. Does anyone know how could I set the size of a textfield? Take this as example: Telefone = schema.TextLine(title=_(uTelefone para Contato), required=True) Is there an attribute like size or something? No, use CSS for layout. :) That depends on the type of input you want to influence. For text input elements the size attribute indicates the maximum number of characters a user can input in the field, and you can not control that using CSS. Well, okay. But still this information must not be put into the schema/interface but in the form. Often you also want to put a different CSS class or id on the different type of input fields. You do not want your checkboxes to be just as wide as your text input fields! a) input[type=text] b) You should have the widget id/name as id on the input field or some containing div. Regards, -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: testing a meta-egg
On 2008-04-07 13:12:15 +0200, Jim Fulton [EMAIL PROTECTED] said:
It might be better to just provide a variable containing all the
dependent eggs like ${test:dependent-eggs}. You could do what ever you
want then.
How would that help?
Oh, when writing that mail I thought one could do
[test]
eggs = foo
${test:dependent-eggs}
But unfortunatly to understand recursion you have to undertand
recursion. So this would only work to test the dependent eggs of
another section. But forget about that.
Regards,
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
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 )
[Zope-dev] Field for blobs?
Hi, I'd need a zope.schema field for blobs. Should this go directly to zope.schema or some third party package? Something like bla = zope.schema.Blob(title=...) would be nice to have. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: AW: Field for blobs?
On 2008-04-16 10:01:30 +0200, Nikolay Kim [EMAIL PROTECTED] said: On Tue, 2008-04-15 at 17:37 +0200, Roger Ineichen wrote: The other option whould be to split every widget into it's own package and use z3c.widget as namespace package. What do you think? i think we should split z3c.schema and z3c.widget to separate packages, so we can have one namespace for all third party fields and widgets actually, when the __init__.py of z3c.schema would be a namespace __init__.py one could just add new packages w/o the need to split the z3c.schema up. Even though this might be a bit confusing. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: Splitting up zope.app.container
On 2008-04-16 18:34:44 +0200, Malthe Borch [EMAIL PROTECTED] said: The ``constraints`` module in zope.app.container seem to be usable outside a ZODB-application---ditto most of the interfaces. If we want to support a nozodb-environment, it would be nice to not have to pull in ZODB just to get these frameworky definitions. Is it package overkill to move these out to, say, zope.container? +1 Also the container interfaces could be moved there. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: zope.app.locales i18nmergeall.py not used anymore?
On 2008-04-26 10:25:16 +0200, Christophe Combelles [EMAIL PROTECTED] said: Maurits van Rees a écrit : Hi, zope/app/locales/TRANSLATE.txt says: ... After that, you need to merge those changes to all existing translations. You can do that by executing the ``i18nmergeall.py`` script from the ``utilities`` directory of your Zope 3 checkout: $ python utilities/i18nmergeall.py -l src/zope/app/locales So I tried that and found that in the 13 po files that are present, over 80 thousand lines were changed (counting all lines in an svn diff). Since the files combined have about 100 thousand lines, this could be called a fairly big change. :) So: is there a reason this merging is not regularly done anymore? Or can I just go ahead and submit those 80 thousand lines? It seems too big, that's weird. I think merging is not really done, and there are several changes to do f or i18n: - split the zope gettext domain into all the separate namespaces. Maybe only zope.app.* packages can be kept under the zope.app domain. I think each and every package should have its own domain. Should we just start with that for 3.5 packages? Would this break anything? - find a way to generate the .pot and .mo files at build. They should not be stored in the svn. We should only have the translated .po files, and the merging and compiling should be done during build. Maybe the .pot file could be a lso stored but this is not really necessary. Yeah, the .mo files don't need to be stored indeed. But that's not really high priority I think. - add an automatic test in each package to check whether the .po files ha ve been merged by the developer. If a po file is not in sync with the code, the t est fails. This would allow all the .po files to be always up to date. Actually I don't really use the merge script. I prefere using somethink like poedit and its update from pot file feature. This also tells me what I have to translate and what is gone. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: New i18n locale extraction concept
On 2008-05-01 02:06:17 +0200, Roger Ineichen [EMAIL PROTECTED] said: What does this mean? The locale extraction is now a part of a recipe and not a part of a package itself. My goal is to remove the dependencies in the z3c.recipe.i18n, because right now it uses the base implementation in zope.app.locales which makes it depend on the hole zope namepsace. Because of the overall zope.* dependenc in zope.app.locale. Actually, there is lovely.receipe:i18n which provides i18n extraction. Does z3c.recipe.i18n something else or why is there yet another i18n recipe? The best option whould be to split zope.app.locales into usefull packages. The not so good optipon whould be to copy over the relevant classes and scripts to the recipe and skip the dependency to zope.app.locale. I also started to use the recipe in z3c.locales and zam.locales. Take a look at this package for a real usecase. What do you think? Should we switch the locale extraction to that concept for the zope.* packages too or not? Exctaction should be in a recipe, of course. But I'm also advocating for having the translations in the package and having one domain per package. ` -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ 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 )
[Zope-dev] Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On 2008-05-10 19:38:15 +0200, Martijn Pieters [EMAIL PROTECTED] said: On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: zcml is a pretty simple format though: xml with only human readable text in title and description attributes (and perhaps a few others) and the translation domain specified in a i18n_domain attribute. It should be quite trivial to extract that data without having to pull all of zope in. If you determine beforehand which strings are translatable (end up as msgid objects) it should be trivial to extract these. You will have to update i18ndude to add new zcml tags though. What's translatable and what not is defined by the schema of the configuration which can be extended by any package. So adding this information to the extractor would duplicate it. Not good. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] Re: Deciphering Zope Comments
On 2008-06-04 20:28:07 +0200, Dieter Maurer [EMAIL PROTECTED] said: Shane Hathaway wrote at 2008-6-4 00:01 -0600: That led me to the zope.thread module, which is apparently deprecated already, yet zope.app.component still depends on it. Is that an hysterical accident? As I have read, thread local variables have been invented and implemented in Zope 3 land and donated to Python. Now, that it is in Python, the original Zope implementation can go away. Maybe, that is the purpose of the zope.thread module? Actually zope.thread does nothing but importhing the python implementation. The module is there for backward compatibility. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] Re: zc.testbrowser.real support for mozlab 0.1.9
On 2008-07-04 01:19:47 +0200, Graham Stratton [EMAIL PROTECTED] said:
I've checked in a branch with changes to the testbrowser.real code to
make it work with mozlab 0.1.9 (and firefox 3).
Hi Sebastian,
This is great. I spent all day yesterday trying to make this happen
and didn't get anywhere. Sometimes I wake up with a better idea as to
how to solve things, but I don't often wake up to find all the work's
been done!
I tried running the tests with Python 2.4. About half the time they
pass fine, and the other half fail something like this:
File doctest README.txt[40], line 1, in ?
browser.open('navigate.html')
File /Users/graham/development/patched_zc.testbrowser/src/zc/
testbrowser/real.py, line 201, in open
self.wait()
File /Users/graham/development/patched_zc.testbrowser/src/zc/
testbrowser/real.py, line 193, in wait
assert self.execute('tb_page_loaded;') == 'false'
AssertionError
though for varying pages with browser.open(). I don't understand what
could be causing it; why would that value be changed in between those
two lines? I guess the time.sleep() on line 191 implies that there's
something we might want to wait for. I increased it by 10x and only
got 1 failure out of 10, so I guess that helps.
I had this error, too and checked in a maybe-fix in r87964. Have you
tried with this revision or the one before? If it's thisone I'll add
another loop there.
--
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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 )
Re: [Zope-dev] Make simple ISource usable
On 2008-08-30 16:54:57 +0200, Roger Ineichen [EMAIL PROTECTED] said: Hi Chritian Betreff: Re: [Zope-dev] Make simple ISource usable On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote: [...] The only query API defined for ISource in zope.schema is the ISourceQueriables API. That's defently to less and makes it required to implement custom query APIs in UI frameworks if we need to work with terms. I no one objects, I'll start a zope.schema branch and let you know about the progress and a hopfully a simple solution. Additional to them I started allready a z3c.form branch for adjust the ITerms implementation. As far as I can see right now this refactoring will only provides additional features. What do you think? Any objections or hints about that? Terms require access to a request. Any application's model code should be happy to only deal with the values of sources. I agree, ITerm lookup from an ISource should work without the request. Terms are used to map values to the UI parts of an application (by providing identification tokens and user readable titles). IMHO zope.schema doesn't need to know about terms. I agree if you think about the ITerms adapter pattern like defined in zope.app.form using (source, request) as discriminators. Which would be good. The term could very well be different in different skins, could it not? At least the title is language dependent (hm, okay, translation comes later...) But zope.schema does already know about term. ITerm is a part of zope.schema. ISource uses ITerm as items. But No, ISource contains just values, i.e. ISource can contain any python object. It doesn't even say that there must be a way to create a Term vor a value. the only query API is ISourceQueriables. There is no simple query API for work with terms. You'd probably convert a term to a value and then look it up in the source. This of course works (inefficiently) for IIteralbeSources. But you cannot search a plain ISource (besides plain containment) so that's not a problem. Also it is good that ISource is not iterable, because it is of couse possible to define non-iterable sources. I do agree that the whole issue of searching/querying sources is currently underdesigned. What do you think about an ITerm interface next to the ISourceQueriables interface. This interface could offer getTerm and getValue and offer a base for access none queriable ISource implementations. Of corse such a ITerms adapter for ISource doesn't adapt the request. The PrincipalSource ITerms implementation from zope.app.security doesn't even use the implemented request. Probably we should named the new interface in zope.schema ISourceTerms instead of ITerms? Wait. zope.schema really shouldn't know about terms. Terms are about the user interface, hence title/token. That has really *nothing* to do with zope.schema. For searching you don't need titles or tokens. For a search *UI* you do, but that doesn't belong to zope.schema either. Regards, -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Make simple ISource usable
On 2008-09-01 06:58:16 +0200, Christian Theune [EMAIL PROTECTED] said: Hi, sorry for removing all the quotes, but I need to clarify your baseline question a bit. On Sun, 2008-08-31 at 23:23 +0200, Roger Ineichen wrote: Yes exactly, it's up to the developer how they implement something useful for handle ISource objects. =20 If it comes to implement a widget framework is looks a little bit different. A widget framework can define an API which othter can use. ITerms in zope.app.form does that already. You can do what ever you need to do in such an ITerms adapter for access the ISource and return standard ITerm objects which the widget can handle. =20 The ITrems is a standard API for handle ISource, doesn't nmatter how you will query or get our data form an ISource. This sounds like you want to implement something different than ITerms but that you see a structural similarity between what you want and what ITerms already do. I think this causes some confusion (and resistance by my side) right now. Can you try to phrase what you want to achieve and maybe not use the word 'ITerms' (for now)? Right. What's the difference from the ITerms we have now? Why do I need it? -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Make simple ISource usable
On 2008-08-31 22:51:38 +0200, Marius Gedminas [EMAIL PROTECTED] said: On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote: Wait. zope.schema really shouldn't know about terms. Terms are about=20 the user interface, hence title/token. That has really *nothing* to do=20 with zope.schema. For searching you don't need titles or tokens. For a=20 search *UI* you do, but that doesn't belong to zope.schema either. Are you arguing that zope.schema.Field should not have a title attribute? No no no, sorry :) I only don't see why I need titles for a source all the time. If you need both tied toogether (which frankly quite often is the case) zc.sourcefactory does the right thing (for me). If you just need to define a set of values you can just define the source (i.e. __contains__). -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] ForbiddenAttribute: why subclass AttributeError?
On 2008-10-15 17:49:30 +0200, Christian Theune [EMAIL PROTECTED] said: Why is a ForbiddenAttribute also an AttributeError? Is this intended to avoid 'information leaks'? We found a nasty side-effect together with getattr and annotations: a user that didn't have read-access to __annotations__ would end up trying to create the annotations container again and again because getattr(obj '__annotations__', None) would return None instead of propagating the ForbiddenAttribute exception. On a proxied object you'd never get an AttributeError but only ForbidenAttribute, wouldn't you? So I think an ForbiddenAttribute as subclass of AttributeError is the right thing. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] zope.testbrowser: Newlines in textarea not always preserved
Hi, a few weeks ago I posted a bug regarding zope.testbrowser: https://bugs.launchpad.net/zope3/+bug/268139 »When there is XML or HTML-Code in the Textarea the newlines are removed.« Could anybody give me a hint how to fix it? I'd really apprechiate it because it prevents me from using Python 2.5 :) Regards, -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] z3c.autoinclude doesn't include extra_requires
Hi, when I include an egg with extras (like gocept.foo[server]) the dependencies from the extra are not automatically included with autoinclude. I'm posting this here, because there is no other obvious place (no project for this on lauchpad). Regards, -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] deprecate http://download.zope.org/distribution
On 2008-11-12 23:41:55 +0100, Jim Fulton [EMAIL PROTECTED] said: http://download.zope.org/distribution was set up as a place to publish distributions while we were learning about setuptools, eggs, and pypi. I think now, we're all using PyPI (or local repositories). I'd like to deprecate this site, making it read-only for now, but eventually removing it. Yeah, make it read only. But I'd just leave it there. We have the policy of not removing eggs which are out there, so I suggest leaving the eggs there. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On 2008-12-08 18:23:33 +0100, Tres Seaver [EMAIL PROTECTED] said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Nope, the tests will pass in the zope.testbrowser buildout. Having tests which pass only in that buildout is an attractive nuisance: I'm seeing test failures in the version of zope.testbrowser linked into the Zope2 trunk, for instance. If the behavior of zope.testbrowser is broken in the absence of a sufficiently-recent version of ClientForm, then that behavior should be spelled out in setup.py's dependencies: that is what they are for. That's the way I think of it, too. Also the bug introduced by an older ClientForm is so subtle that it is not immediately obvious that it is the testbrowser which is broken. It may if you just got an upgrade, but not if you setup your things and it just behaves strange. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Here's a scenario: I fix a bug in some package, it depends on a newer version of say, zope.publisher. I put that requirement in my package's setup.py. A user of my package upgrades to get an unrelated bug fix and is forced to use the newer zope.publisher. It so happens that that the new version of zope.publisher has a different bug that bites them. They now are in a bad spot. A user of your package cannot rely on automatic dependency resolution in this case: your package is broken without the new version of its own dependency, so they can't upgrade to it. Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: at that point, forking the egg to drop the manually-resolved extra dependency is a minor nuisance. Agreed. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] zope.browser?
On 2008-12-11 17:13:06 +0100, Roger Ineichen d...@projekt01.ch said: Hi Martijn Betreff: Re: [Zope-dev] zope.browser? Martijn Faassen wrote: Hi there, I saw that Roger Ineichen created and released a package called zope.browser. I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me? Looking more, I've noticed that zc.sourcefactory replaces the dependency on zope.app.form with this package. That seems to be an improvement. Since I'm quite interested in this project, I'd like to hear much more about how we will determine which kind of dependency surgery we'll do next. I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form) That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] zope.browser?
On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-12 16:04:09 +0100, Robert Niederreiter r...@squarewave.at said: Hi, Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick: On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-15 13:44:43 +0100, Roger Ineichen d...@projekt01.ch said: Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. Depends. See below. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. Yes, for necessary API changes which do not need to be shipped immeadiately I can see that. btw, we also should deprecate the ISite interface at the old location. Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
On 2008-12-22 18:48:47 +0100, Martijn Faassen faas...@startifact.com said: Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the preferred import location of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. Right. May I remove the deprecation warning then? I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the right public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] Release zc.selenium on pypi
Hi, there is zc.selenium on svn.zope.org which is not on pypi. Could this be released? Also it speaks of the ZVLS in some files which doesn't seem to be correct. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Release zc.selenium on pypi
On 2009-01-07 14:32:07 +0100, Benji York be...@zope.com said: On Wed, Jan 7, 2009 at 7:29 AM, Christian Zagrodnick c...@gocept.com wrote: there is zc.selenium on svn.zope.org which is not on pypi. Could this be released? Yes. Also it speaks of the ZVLS in some files which doesn't seem to be correct. It's not correct. They should all be ZPL. Just released 1.1.0 and added you as owner. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] release of lovely.remotetask?
Hi, I'd like to create a new release of lovely.remotetask. Could somebody give me (zagy) the pypi rights? Thanks, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] z3c.recipe.i18n tests break on unix
Hi,
the tests of z3c.reipce.i18n break on unix systems, for instance with:
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18ncompile-script.py
- i18ncompile.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18ncompile
- i18nextract
- i18nmergeall
- i18nstats
What's the general way of testing those things in both environments? I
don't have a windows box to test this. I also see most recipes are
tested only for unix (which would be fine for me).
How should we proceed in this special case? Actually there is a bug
which I'm going to fix w/o having passing tests now.
Regards,
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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 )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
On 2009-05-15 12:16:30 +0200, Roger Ineichen d...@projekt01.ch said: Hi Christian What's the general way of testing those things in both environments? I don't have a windows box to test this. I also see most recipes are tested only for unix (which would be fine for me). How should we proceed in this special case? Actually there is a bug which I'm going to fix w/o having passing tests now. I'm fine if you switch the tests that they pass on linux and will break on windows. I can catchup the tests later and try to make them running again on windows and linux. Okay, would you give me the pypi access (user zagy)? Thanks a lot for help improve missing parts or fix issues! np, after all I want to use it :) -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zope.app.publisher/trunk/ To make browsers update their caches of resources immediately when the
Hoi, On 2009-06-09 15:51:03 +0200, Stephan Richter srich...@cosmos.phy.tufts.edu said: On Tuesday 09 June 2009, Wolfgang Schnerring wrote: To make browsers update their caches of resources immediately when the resource changes, the absolute URLs of resources can now be made to contain a hash of the resource's contents, so it will look like /++noop++12345/@@/myresource instead of /@@/myresource. - Implemented an AbsoluteURL adapter that computes a hash of the resource's contents and inserts that into the URL. - Content hashes will be cached in memory, except when in developer mode - Introduced a ++noop++ traverser that simply throws away the path segment - Wrote a bit of documentation about resources Mmmh, this looks like a lot of extra code to get behavior that is served better with different tools. Have you looked at z3c.versionedresource and z3c.traverser? Both of those should solve these type of use cases well. The checkin actually is two in one (which aruably is not such a good thing): 1. Make resources compute urls with an IAbsoluteURL adapter so they behave like every other object. 2. Provide an optional hashing adapter (and the ++noop++ namespace). I don't think we have to argue about 1. The ++noop++ and hashing could easily be moved to a different package. The idea behind the hasing is that one should not have to think about new versions or cache invalidations. That's also why in development mode the hash is computed every time and not just once: It aids development a lot. But it helps in deployment as well of course. So, why in a zope package? Because I really think this is a core issue of a web framework. Do we really want to not change any zope.* package any more in regard to new features? Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] zope.testing: Define __add__ for RENormalizing
Hi, I suggest defining __add__ for zope.testing.renormalizing.RENormalizing which would return a new Checker with the transformers combined. This allow better reuse of those checkers without having to define the patterns separately. Like checker = checker_a + checker_b. Comments? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] zc.zope3recipes:instance: zdaemon/eventlog rotatation
Hi, The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes the transcript_log and zdaemon's eventlog to the same file. That's actually fine. ZDaemon's reopen_transcript does exactly that: it reopens *only* the transcript. So when rotating the logfile (as zc.zope3recipes does it via logrotate) ZDaemon messages still go to the old logfile. I see two obvious ways to fix that: a) Write ZDaemon's eventlog to stdout b) Add a sane way to reopen the logfile. There is a logreopen command in ZDaemon but that actually restarts the daemon process. Comments? Suggestsions? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] zc.zope3recipes:instance: zdaemon/eventlog rotatation
On 2009-09-16 13:03:44 +0200, Jim Fulton j...@zope.com said: On Wed, Sep 16, 2009 at 5:28 AM, Christian Zagrodnick c...@gocept.com wrote: The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes the transcript_log and zdaemon's eventlog to the same file. That's actually fine. ZDaemon's reopen_transcript does exactly that: it reopens *only* the transcript. So when rotating the logfile (as zc.zope3recipes does it via logrotate) ZDaemon messages still go to the old logfile. I see two obvious ways to fix that: a) Write ZDaemon's eventlog to stdout That won't help. The messages are coming from the controller. Well, I think it helps in the way, that the messages are not written to a logfile. Thus nothing needs to be reopend or rotated. They won't be stored anyware obviously. b) Add a sane way to reopen the logfile. There is a logreopen command in ZDaemon but that actually restarts the daemon process. Comments? Suggestsions? The controller needs to be more careful about how it manages it's log file. It needs to keep track of the handler used and, when the transacript file is reopened, it needs to remove the old handler it was using and create a new one. This is probably complicated by ZConfig which is managing the logging configuration. This is easy to deal with if you're willing to rely on the logging systems internal details. :) Eeek :) Oh I'm not sure if it is complicated. But I'll have a look into it when I've got some time. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] z3c.recipe.i18n tests fail
Hi,
the tests fail with the following error:
Running zope.testing.testrunner.layer.UnitTests tests:
Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line 2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line 464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
I actually have no idea why this is happening. Anybody got a clue?
Regards,
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] z3c.recipe.i18n tests fail
On 2009-12-01 16:36:50 +0100, yuppie y.2...@wcm-solutions.de said:
Christian Zagrodnick wrote:
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line
2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line
464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
Should be fixed now. Yuppie
Thanks! And it was such an easy fix! :)
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] zope.testing: Define __add__ for RENormalizing
On 2009-06-18 10:00:01 +0200, Christian Zagrodnick c...@gocept.com said: Hi, I suggest defining __add__ for zope.testing.renormalizing.RENormalizing which would return a new Checker with the transformers combined. This allow better reuse of those checkers without having to define the patterns separately. Like checker = checker_a + checker_b. Finally got that in: r106221. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] Generations in Zope 2
Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Generations in Zope 2
On 2009-12-15 11:20:19 +0100, Wichert Akkerman wich...@wiggy.net said: On 12/15/09 11:02 , Christian Zagrodnick wrote: Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? -1, this would add a needless dependency on zope.app.generations to Zope 2 as far as I can see. Why not move include this in zope.app.generations itself in a [zope2] extra ? Or create a tiny five.generations package to do this. five.generations is part of five enough for me ;) I don't like an zope2 extra for zope.app.generations. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] Update ZTK: zc.resourcelibrary 1.3.1
Hi, I just released zc.resourcelibrary 1.3.1. IMO the ZTK should be updated accordingly. Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Update ZTK: zc.resourcelibrary 1.3.1
On 2010-03-24 12:12:07 +0100, Baiju M mba...@zeomega.com said: On Wed, Mar 24, 2010 at 3:06 PM, Christian Zagrodnick c...@gocept.com wrote: Hi, I just released zc.resourcelibrary 1.3.1. Great ! IMO the ZTK should be updated accordingly. +1 done (r110171) -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] IAbsoluteURL for browser view should contain @@?
Hi, the explicit way to address a view is using the /@@viewname namespace traversal. An IAbsoluteURL for a browser view returns an URL without the @@ (i.e. /foo/bar/view instead of /foo/bar/@@view). I think this should be changed so that the URL contains the @@. If you agree with this, where should I place this adapter? The two relevant interfaces are zope.browser.interfaces.IBrowserView zope.traversing.browser.interfaces.IAbsoluteURL But neither package depends on the other, so a different package might be more suiteable? Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] IAbsoluteURL for browser view should contain @@?
On 2010-04-01 12:31:10 +0200, Jacob Holm j...@improva.dk said: Marius Gedminas wrote: Are you sure that most views provide IBrowserView these days? URL traversal looks them up as multi-adapters providing just Interface. True and you will almost never see a view class using implements(IBrowserView) directly. Still, if you use the browser:view or browser:page zcml directives from zope.browserpage (used to live in zope.app.publisher.browser) to register your views, then the magic class that they create for you and that is *actually* registered is a descendant of zope.publisher.browser.BrowserView which *does* implement IBrowserView. Yes indeed. One problem I found already is, that the FileResource is more an IBrowserView than an IResources currently. That is currently registering an IAbsoluteURL adapter for IBrowserView will break the URL for file resources. But that's solvable. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] ZConfig + SMTP Auth email logger
Hi, I just added SMTP authentication to the email notification logger in ZConfig. Would somebody make a release please or give me (zagy) the proper PyPI rights? Thanks, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
[Zope-dev] zope.server: Exception during task logging
Hi, zope.server logs the Exception during task message to the root logger. So there is no (easy/useful) way to filter that. I'd like to change this logging to a zope.server logger. (i.e. using logging.getLogger(...)) Objections? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] zope.server: Exception during task logging
On 2010-04-14 14:58:47 +0200, Christian Zagrodnick c...@gocept.com said: Hi, zope.server logs the Exception during task message to the root logger. So there is no (easy/useful) way to filter that. I'd like to change this logging to a zope.server logger. (i.e. using logging.getLogger(...)) Objections? Since there where none thats implemented in r112771. Would somebody make a release or give me (zagy) the pypi permissions? Thanks, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] zope.server: Exception during task logging
On 2010-05-27 16:44:58 +0200, Tres Seaver tsea...@palladion.com said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Zagrodnick wrote: On 2010-04-14 14:58:47 +0200, Christian Zagrodnick c...@gocept.com said: Hi, zope.server logs the Exception during task message to the root logger. So there is no (easy/useful) way to filter that. I'd like to change this logging to a zope.server logger. (i.e. using logging.getLogger(...)) Objections? Since there where none thats implemented in r112771. Would somebody make a release or give me (zagy) the pypi permissions? I just added you. Thanks. I just released it. (3.6.2) -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Can ZTK 1.0 support Python 2.7?
On 2010-07-13 14:12:01 +0200, Hanno Schlichting said: Hi. We have Python 2.7 final now and some work has begun on making ZTK packages compatible with it. Currently we still see various test failures in the zopeapp set though and nobody who steps up to fix them. Apart from that, we have made a promise to support Python 2.4 up to 2.6 for the ZTK 1.0 release. The ZODB 3.10 releases do no longer support Python 2.4 but require 2.5. The ZODB 3.9.x releases are in maintenance mode for a while and currently don't support Python 2.7. I doubt that we can get official 2.7 support for the 3.9.x release line. Given all of these, I'm leaning towards not supporting Python 2.7 for a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to support 2.7 in addition. Yes, ZTK 1.0 should become stable/released soon. Adding a new Python version or removing one, doesn't help. But I really want to see Python 2.7 support rather soon. So how do we actually proceed there? Even after ZTK 1.0 is out, how is the transition made to 1.1? I suppose there could be a 1.0.1 at the same time as a 1.1.0. Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Can ZTK 1.0 support Python 2.7?
On 2010-07-13 20:37:42 +0200, Tres Seaver said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Zagrodnick wrote: On 2010-07-13 14:12:01 +0200, Hanno Schlichting said: Hi. We have Python 2.7 final now and some work has begun on making ZTK packages compatible with it. Currently we still see various test failures in the zopeapp set though and nobody who steps up to fix them. Apart from that, we have made a promise to support Python 2.4 up to 2.6 for the ZTK 1.0 release. The ZODB 3.10 releases do no longer support Python 2.4 but require 2.5. The ZODB 3.9.x releases are in maintenance mode for a while and currently don't support Python 2.7. I doubt that we can get official 2.7 support for the 3.9.x release line. Given all of these, I'm leaning towards not supporting Python 2.7 for a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to support 2.7 in addition. Yes, ZTK 1.0 should become stable/released soon. Adding a new Python version or removing one, doesn't help. But I really want to see Python 2.7 support rather soon. So how do we actually proceed there? Even after ZTK 1.0 is out, how is the transition made to 1.1? I suppose there could be a 1.0.1 at the same time as a 1.1.0. As soon as we get to 1.0b1, the release team will make a 'branches/1.0' branch for stabilization, and the trunk can then be updated to drop 2.4 support and add 2.7 support. Actually I was thinking about the individual packages. I assume dropping Python 2.4 should bump the respective package version at least from 1.x.y to 1.x+1.0, right? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-15 15:26:28 +0100, Hanno Schlichting said: On Tue, Feb 15, 2011 at 2:35 PM, Michael Howitz m...@gocept.com wrote: When I have an acquisition wrapped object, e. g. my_object and call: unicode(my_object) The method __str__ of my_object is called even when it has an __unicode__ method. Acquisition wrappers only fill the tp_repr and tp_str slot and as far as I can tell there's no tp_unicode slot in PyObject_HEAD_INIT. So I'm not sure how to add the C equivalent of a __unicode__ to the Wrappertype and XaqWrappertype PyExtensionClasses. It would probably have to do a lookup for a __unicode__ method on the wrapped instance, call it if it exists and otherwise call its own __str__ - essentially duplicating the logic of the string type. Jup. My C-fu is too weak to attempt this. Heh. My C-fu is also rather weak but I might try it if there are no objections. (or there is somebody hacking it in 5 minutes …) The workaround is to call unicode(aq_base(my_object)). Yes, but that's not really an option. Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-16 10:10:05 +0100, Hanno Schlichting said: On Wed, Feb 16, 2011 at 9:18 AM, Michael Howitz m...@gocept.com wrote: Zope 2.12.8 on Python 2.6 breaks the same way as 2.13. But Zope 2.11.7 on Python 2.5 works correctly. So either Python or Acquisition must have changed since than. Acquisition changed a lot from 2.11 to 2.12 - it got support for parent pointers for example. The full changelog is quite long, but should be unrelated (http://pypi.python.org/pypi/Acquisition#changelog). The full diff is at: svn di svn+ssh://svn.zope.org/repos/main/Acquisition/branches/2.11/src/Acquisition/_Acquisition.c svn+ssh://svn.zope.org/repos/main/Acquisition/trunk/src/Acquisition/_Acquisition.c There's nothing obvious I can see here. I suspect a change in python (which I did not follow up after getting strange feelings when looking at PyObject_Unicode). Nevertheless I've fixed that on a branch: svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called Hanno: Would you review that change please? Thanks. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-16 22:22:53 +0100, Hanno Schlichting said: On Wed, Feb 16, 2011 at 10:19 PM, Christian Zagrodnick c...@gocept.com wrote: I suspect a change in python (which I did not follow up after getting strange feelings when looking at PyObject_Unicode). Nevertheless I've fixed that on a branch: svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called Hanno: Would you review that change please? Sure. I'll review, merge and release. Should be sometime this week, cannot promise a day. Thanks. There is no pressure. mr.developer FTW :) Anyway, I've added another test to make myself more comfortable. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-19 17:17:44 +0100, Hanno Schlichting said: On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnick c...@gocept.com wrote: On 2011-02-16 22:22:53 +0100, Hanno Schlichting said: svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called Sure. I'll review, merge and release. Should be sometime this week, cannot promise a day. Branch reviewed, merged and released in Acquisition 2.13.6. Could you remove the merged branch once you updated your buildout config? Done. Thanks for releasing! -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-25 21:56:49 +0100, David Glick said: On 2/20/11 1:32 AM, Christian Zagrodnick wrote: On 2011-02-19 17:17:44 +0100, Hanno Schlichting said: On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnickc...@gocept.com wrote: On 2011-02-16 22:22:53 +0100, Hanno Schlichting said: svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called Sure. I'll review, merge and release. Should be sometime this week, cannot promise a day. Branch reviewed, merged and released in Acquisition 2.13.6. Could you remove the merged branch once you updated your buildout config? Done. Thanks for releasing! This change introduces a regression when calling unicode on wrapped objects that implement __str__ but not __unicode__. Essentially it is now doing the equivalent of str(aq_base(obj)) ... __str__ used to get a wrapped object as 'self', but now it is unwrapped. Here's a failing test that can be added to Acquisition's TestUnicode test case to demonstrate the issue: def test_str_fallback_is_still_wrapped(self): class A(Acquisition.Implicit): def __str__(self): return str(len(Acquisition.aq_chain(self))) wrapped = A().__of__(A()) self.assertEqual(u'2', unicode(wrapped)) This is currently causing some regressions in Plone tests. I'll have a look at it. Thanks for spotting that. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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] Acquisition wrapped objects do not behave well on unicode call
On 2011-02-28 07:43:55 +0100, Christian Zagrodnick said: On 2011-02-25 21:56:49 +0100, David Glick said: On 2/20/11 1:32 AM, Christian Zagrodnick wrote: On 2011-02-19 17:17:44 +0100, Hanno Schlichting said: On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnickc...@gocept.com wrote: On 2011-02-16 22:22:53 +0100, Hanno Schlichting said: svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called Sure. I'll review, merge and release. Should be sometime this week, cannot promise a day. Branch reviewed, merged and released in Acquisition 2.13.6. Could you remove the merged branch once you updated your buildout config? Done. Thanks for releasing! This change introduces a regression when calling unicode on wrapped objects that implement __str__ but not __unicode__. Essentially it is now doing the equivalent of str(aq_base(obj)) ... __str__ used to get a wrapped object as 'self', but now it is unwrapped. Here's a failing test that can be added to Acquisition's TestUnicode test case to demonstrate the issue: def test_str_fallback_is_still_wrapped(self): class A(Acquisition.Implicit): def __str__(self): return str(len(Acquisition.aq_chain(self))) wrapped = A().__of__(A()) self.assertEqual(u'2', unicode(wrapped)) This is currently causing some regressions in Plone tests. I'll have a look at it. Thanks for spotting that. Fixed in r120651 (trunk) - Fixed bug: When an object did not implement ``__unicode__``, calling ``unicode(wrapped)`` was calling ``__str__`` with an unwrapped ``self``. Is the situation with Plone better now? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone 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 )
