December 2003 - Zope-Dev

app = Zope.app() backwards incompatibility notice / discussion
by Chris McDonough 16 Feb '04

16 Feb '04

The extant "import Zope; app = Zope.app()" dance to get a hold of the Zope root object stopped working long ago on the 2.7 branch and HEAD due to the new configuration machinery, which implies that users be explicit about configuration settings rather than allowing Zope to guess. Up til now, the dance to get Zope 2.7 to start properly from within a script was byzantine and obscure. I've made a checkin which makes it a little easier (or at least I'm about to as soon as the full unit test suite comes back passed ;-). Code which used to do: import Zope app = Zope.app() Will need to do this under 2.7b4+: import Zope Zope.configure('/path/to/configfile') app = Zope.app() (I wont bother telling you what the dance was for 2.7 before now, it was pretty awful). I realize this is suboptimal from a backwards compatibility perspective, but I'm not sure how to make it any better, seeing as the config file has some fairly important information in it (like which databases to use) and guessing would be very bad in this context. Jim Roepke suggested that if an "ZOPE_CONFIG" envvar was set with the config file path, that "import Zope; Zope.app()" could be made to "just work", but I'm not sure this is any better than requiring that developers change their scripts. Guessing at the config file location is also fraught with problems, and I'd be hesitant to do it. I'm apt just to recommend that we require that developers add the "Zope.configure(filename)" line to their scripts as opposed to doing anything more magical. I'm sure there will be indignant wails about it, but c'est la vie. ;-) Note that FWIW, you can also do (on UNIX): zopectl run <scriptname> .. which will run a script with the name "app" set up as the root Zope application object. This might be the easiest way to run scripts which need to operate against Zope objects going forward. - C

5 7

[ZConfig] wishlist
by Dieter Maurer 02 Jan '04

02 Jan '04

Today, I incorporated our Zope extensions into Zope 2.7 and had to determine how I can provide the necessary configuration through ZConfig. I feel the configuration process is not yet as modular as it should be? Let's explain what extensions I have: 1. an alternate "Transience" implementation for Zope sessions 2. a new log handler "rotated_logfile" (which performs automatic daily rotation with log files named "prefix.date") 3. a common piece of configuration used for communication between Zope and a "checkZope" process (which supervises that Zope responds sufficiently fast) I solved 1 and 2 by rudely modifying Zope sources ("zLOG/component.xml" and associated "handlers", "Zope/Startup/zopeschema.xml" and associated "handlers"). I do not yet have a solution for 3 but I probably will give the "checkZope" process the complete Zope schema and configuration file. Almost surely, it would not have been necessary to modify the "zLOG" configuration to get a "rotated_logfile" because components and sectiontypes provide enough modularity. However, schemas and configuration files seem not to be modular. I would like to compose schemas and configuration files from components: e.g. combine the standard Zope schema and a small schema for our extensions to form the schema used by the extended Zope, combine the configuration file from long living Zope settings (maintained in CVS), instance specific Zope settings (locally maintained) and configuration fragments used by Zope and other components (e.g. the "checkZope" process). I think, a general "include" function for schemas (including not only types but complete schemas) and configuration files could provide this kind of modularity. -- Dieter

3 6

more persistent mapping misery
by Chris McDonough 01 Jan '04

01 Jan '04

Hi folks, On the HEAD recently, a bunch of changes were made to the Persistence package. Notably, the Persistence.PersistentMapping module was removed in favor of a Persistence.mapping module. Unfortunately, there are instance pickles lying around in any CMF instance created prior to the changes (DiscussionItem's _container attribute is the one I found) which explicitly refer to Persistence.PersistentMapping.PersistentMapping. This name can no longer be resolved to a class. This breaks b/w compatibility. I "fixed" the issue by adding the following to the Persistence package's __init__.py: sys.modules['Persistence.PersistentMapping'] = sys.modules['Persistence.mapping'] That seems really ugly, though. Is there a better way to fix it? - C

2 2

Fwd: [Zope CMS contracting work ]
by Paul Resnikoff 31 Dec '03

31 Dec '03

Hi, My firm Mint Modern Media developed positivenature.org using the Zope web server application. I need someone now to develop a Content Management System in Zope according to the spec: http://dmn.zopesites.com/positivenature.org/docs/cms_upgrade/spec_html Ready to start this project immediately and am looking for very fast turnaround (and quick payment to you). Everything will be according to spec however I would like to build in an extra 2 hours for unexpected client requests. If you are interested, please contact me at paulr(a)stanfordalumni.org Thanks and happy new year! Paul Resnikoff ____________________________________________________________________ ____________________________________________________________________

1 0

LocalFS does not work with Zope 2.7
by robert 31 Dec '03

31 Dec '03

Hi there, I tried to use LocalFS on a 2.7 (from cvs) Zope. I can add a a LocalFS, but then get a "not found" error, and the folder with the LocalFS in it (not the localFS itself) becomes unaccessible. I tried to debug into LocalFS. However it is beyond my grasp. Any help how to fix this would be appreciated. Robert

2 2

ZConfig: a wish list
by barry＠zope.com 30 Dec '03

30 Dec '03

As I mentioned, I've been experimenting with Mailman 3 lately, using ZConfig as the configuration language for basic functionality. There are many things I like about ZConfig, but of course I have a few nits. Since the wiki Fred created on zope.org doesn't (or didn't) seem to work, I'll post my wish list here. Feel free to tell me why I don't really want what I think I want. :) - import honors prefixy In my schemas, I have a number of import statements, each with package and file attributes (since the default component.xml naming scheme doesn't work for my code layout). Unfortunately, if my <schema> tag has a prefix attribute, import's package attribute doesn't honor it, so there's a lot of duplication. For example: <schema prefix="mailman.config.components"> <import file="databases.xml"> <import file="domains.xml"> ... - $ substitutions in defaults Often, my defaults for keys can be expressed in terms of $ substitutions that are more general for my system. Unfortunately, there doesn't seem to be any way to make this work. ZConfig itself doesn't perform $ substitutions on default values, and there doesn't appear to be a way to get at %define variables from Python. - default sections At some point I thought it might be nice to be able to define default sections, so that you wouldn't have to require something like "<defaultsect/>" in your config file. - Python command substitutions Something like: %define hostname socket.getfqdn() although I know there are some difficult issues with this (imports for one). - attributes default to type When defining a section, if I don't provide a section name, it would be nice if the attribute was defaulted to the section type. E.g. in this example: <section type="databases" name="*" required="yes" attribute="databases"/> IWBNI I didn't have to duplicate the "databases" string. That's it for now. -Barry

3 4

properties.dtml has a problem
by kf 30 Dec '03

30 Dec '03

I've started to use Zope-2.7b3 and found: In Zope-2_7-branch and MAIN-branch, lib/python/OFS/dtml/properties.dtml has a problem. We cannot set non-UTF-8 characters to properties, because the first line, <dtml-call "REQUEST.set('management_page_charset','UTF-8')"> enforce to use UTF-8, etc.. I think Toby Dickenson's modification to Zope-2_6-branch have not reflected to Zope-2_7-branch and MAIN-branch. http://cvs.zope.org/Zope/lib/python/OFS/dtml/properties.dtml.diff?r1=1.12.16 .1&r2=1.8.18.6 http://cvs.zope.org/Zope/lib/python/OFS/dtml/properties.dtml.diff?r1=1.14& It would be appreciated if the modification would be merged. If there is any reason to avoid it, would someone explain why. Best Regards, Kazuya Fukamachi

2 1

ZConfig: Keytype and section type extension
by Fred L. Drake, Jr. 29 Dec '03

29 Dec '03

This is the second of two messages proposing ZConfig changes. "keytype" override and section type extension --------------------------------------------- ZConfig currently requires that derived section types not specify a "keytype" attribute, used to change the interpretation of the keys. The intent is to ensure that keys defined in the base section type will still be recognized and associated with the same (or equivalent) settings for the derived type. In most cases, this is reasonable behavior. Unfortunately, it makes it tedious to specialize general base section types in some cases. Of particular interest is the case of section types that define no specific keys, but accept arbitrary keys using <key name="+" attribute="some_mapping"/> For such cases, it can be desirable to change what keys are inserted into the mapping by changing the keytype of the encosing section type. Allowing keytype overrides would not affect any existing schema, since such schema are currently rejected. One unit test would need to change; the test currently checks that specifying a keytype for a derived section type raises a SchemaError exception. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation

4 8

ZConfig: Section type datatype inheritance
by Fred L. Drake, Jr. 29 Dec '03

29 Dec '03

This past September, Phillip Eby and I discussed a variety of ZConfig issues on one list or another. Two particular issues I've thought more about, and think I'm reversing myself on them. ;-) I'm going to describe each issue in a separate email, including why I've changed my mind about them and what the consequences are for ZConfig users. Please respond to these messages if you think the proposed changes will have a negative impact on working code. "Inheritance" of the datatype when extending a section type ----------------------------------------------------------- Currently, ZConfig section types that "extend" another do not inherit the datatype of the type they extend. Phillip argued that, at least for schema extensions, the datatype should be inherited from the base schema. I thought it better to explicity request the same datatype was a better approach because of way we've been using ZConfig in some of the core packages. Each concrete section type really uses a different datatype; sharing configuration handling is accomplished only within Python. When this is the only way section types are being used, explicit is the only way to do things. While trying to create some fairly basic section types that are easy to specialize using extension, this can be less than desirable. What it boils down to is that it's difficult to create section types that can be easily specialized with a minimum of additional information in the schema; a fair bit of boilerplate is needed to change a small amount of behavior. If we add inheritance of the datatype for section types, this affects only section types that extend another section type where the "base" specifies a datatype and the derived type does not; in that case, the datatype of the base will be used instead of the "null" datatype. If the "null" datatype is needed, section types that expect it to be used can add the attribute datatype="null" to achieve the current effect (in fact, that works now). No existing unit tests are affected. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation

3 2

Zope 2.7 test suite: no longer unit tests
by Dieter Maurer 29 Dec '03

29 Dec '03

The Zope 2.7 test suite no longer fulfills an essential unit test suite requirement: that tests can be run in isolation. Many test files contain "import Zope; Zope.startup()". When run in isolation, many of them fail because "getConfiguration().dbtab" is "None". Some test files seem to hande this configuration issue such that the complete test suite can be used. However, you do not want to analyse singular problems by always executing the complete test suite... -- Dieter

2 1