- Zope-Dev - Zope lists

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

relations in objects
by Jason Corbett 28 Dec '03

28 Dec '03

Hello Zope developers, I'm a newbie (sorry most people have this curse at one point or another). I have read the zope book (or at least most of it), and the zope developer manual. I can't quite figure out how to have relationships between instances of classes in the database. Let me first ask if I'm using zope for the correct thing. I see that a lot of zope products deal with content management, while mine doesn't really. Basically I want to do what I would normally do with mysql and php, but use zope instead. So I need a way to reference in some intelligent way between objects in zope, and I need a way to query for a list of them. I read about ZCatalogs, etc and how you can use that for querying and indexing. That isn't my first priority, so I'll worry about that a little later. Basically I have an instance of a class 'A'. As part of it I need to reference either a single or in some cases multiple instances of class 'B'. Basically I'll have a mix of one-to-one relations and one-to-many. When I'm coding my python class (I'm going to do a product if you can't tell), how would I get a list of the 'B' instances that relate to this object, and how would I store that? The zope developer manual was pretty good for writing classes, and making views on it, but I need to be able to call methods on those instances and return lists of them. Sorry for the long email, I just don't want to leave details out. If you think I'm barking up the wrong tree, and shouldn't be using zope for this, don't be afraid to let me know. Although I will be pretty disappointed, I think zope is exactly what I've been looking for, I can't find anything like it in any other language. Jason Corbett __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

7 10

Zope 3 Newsletter 11
by Gary Poster 23 Dec '03

23 Dec '03

WELCOME TO THE ZOPE 3 NEWSLETTER: ISSUE 11 (23 DECEMBER 2003) Welcome to the eleventh Zope 3 newsletter. Information about Zope 3 and newsletter contributions and suggestions can be found at the bottom of this newsletter. GLOSSARY FOR THE UNINITIATED Encounter a term in this newsletter you don't know? Try this glossary: http://dev.zope.org/Zope3/NewsletterGlossary NEWS SNIPPETS: - Stephan Richter has been doing some important work on documentation, preparing for his SAMS Zope 3 book. See the content so far at http://dev.zope.org/Zope3/DevelCookbook - Zope2 developers: Philipp von Weitershausen prepared slides for the Zope3 Rheinland sprint that discussed Zope3 from a Zope2 developer's perspective. See http://philikon.de/files/zope3-for-zope2-developers.sxi for an OpenOffice.org-format download - Jake (a.k.a. BZ) announces a new Zope site, http://www.zopezone.com/, including a Zope3-specific forum. JIM FULTON: A status update from the Zope Pope Geddon report - Parentgeddon was completed. Context wrappers are no longer used to track object locations. Objects now keep references to their parents using __parent__ attributes. See: http://dev.zope.org/Zope3/ParentGeddon - While working on parentgeddon, I changed the way object-lifecycle events are handled. See: http://dev.zope.org/Zope3/SimplifyObjectLifecycleAndLocationEvents and http://dev.zope.org/Zope3/LocationRelatedEvents - The container API was simplified a bit: http://dev.zope.org/Zope3/ReplaceSetObjectWithSetitem - Adaptergeddon was completed. This is part of a larger project: http://dev.zope.org/Zope3/ComponentArchitectureSimplification Adaptergeddon included: o Support for multi-adapters. Multi-adapters are adapters that adapt multiple objects at the same time. o Replacement of the View, Resource and Skin services with a single presentation service. This included recasting views as multi-adapters for objects and requests and recasting resources as request adapters. An important consequence of this change is that it is now possible to provide views that provide specific interfaces. This will allow a number of presentation frameworks (e.g. traversal and widgets) to be cleaned up a lot. o A major refactoring of the way interface relationships are managed. - Implementing containers has been simplified quite a bit. See http://dev.zope.org/Zope3/SimplifyImplementingContainers and http://dev.zope.org/Zope3/ContainmentConstraints There is a new section in the programmers tutorial: http://dev.zope.org/Zope3/Zope3PythonProgrammerTutorialChapter1 That documents how to create containers. - We are eliminating many services as part of http://dev.zope.org/Zope3/ComponentArchitectureSimplification The sql connection service has been eliminated. We are working on removing the caching, interface and factory services. Site-management views will provide user-friendly interfaces for browsing and managing database connections, caches, interfaces and factories. Sprint Report Bangalore sprint There was a very successful sprint in Bangalore, India December 4-19. See: http://dev.zope.org/Zope3/BangaloreSprint JAN SMITH: Melbourne Summer Sprint! [we received two sprint messages from Jan. The first has the basics, and the second has an exciting update.] Sprint announcement We are going to have a Melbourne Summer Sprint 4th - 9th February. Paying for Jim's air fare has been an Oz Zope community effort with contributions coming from zope businesses and some individuals. Wednesday 4th Feb - Friday 6th Feb - Zope 3 Tutorial workshop: For first time sprinters, attendance at the tutorials is a prerequisite. The tutorial will consist of three days of lecture and hands on sessions run by Jim Fulton. Python experience is required. All welcome to attend the tutorial Saturday 7th February - Monday 9th February Sprint days: Developers who have participated in a sprint do not have to attend the tutorial sessions. Venue:: Trinity College, Melbourne University, Victoria, Australia http://www.trinity.unimelb.edu.au/map/trinity_vista.shtml Melbourne University is 1 kilometre from city centre Facilities: a state-of-the-art Multi-media Room, a second sprinting room and a tiered Lecture Theatre There is low cost accommodation available at the sprint venue - Trinity College More information on the sprint: http://www.ozzope.org/2ndsprint/2ndOzSprintWiki Sprint update The Oz Zope community is excelling itself As well as having enough pledges to pay for Jim Fulton's air fare from the US to Australia. We also have a funding pledge from Melbourne University which will enable us to fly a second person to Australia. Regarding the second air fare, Jim Fulton and I had a couple of hours to choose who would use that second air fare. In deciding we first looked at the suggestions from the Oz Zope meetings and the mailing list. There had been requests to invite to this sprint one of the Lone developers also requests for user interface expert Paul Everett. As luck would have it, there is a Lone snow sprint in Austria the same week as our sprint so no Lone developers are available. Paul Everett reluctantly can't spare the time either he has a project deadline looming. We looked at the people actively working on Zope 3 and chose Garrett Smith from Chicago. GODEFROID CHAPELLE: Page Template "usage" variable Usage in Page templates has been completed during the Rheinland Sprint organized by DZUG. The following text explains the motivation and the use of the usage variable. More information can be found in app/browser/skins/README.TXT The Usage Variable A skin must manage structural elements like navigation, tabs, location breadcrumbs... Skin pages need to show all or some of those elements. o An object view (as in the Rotterdam skin) has a lot of those structural elements. o In dialog-style pages, you don't want elements such as tabs, menus, and the location bar. o For the screen used in adding a new item, you also want many items to disappear, but also to add some information specific to this screen. o In error dialogs, the location bar doesn't work, because errors have no location. One option is to manage multiple versions of the master template and applying them as whole-page macros on the various pages. But multiple master templates is cumbersome and error-prone. To solve this, the skin facility introduces a top-level TAL variable called 'usage'. The usage variable is there to allow you to maintain a unique template for a whole application. This variable has a value that sets different modes of operation. By testing usage, you can decide which blocks should be shown or hidden when rendering the template. Having a unique template eases to enforce a coherent UI and consistent look and feel by ensuring that structural elements do not move too much on the screen. The main way to set the value of 'usage' for a page is through the menu it is registered to. A menu is a set of conceptually related links to pages. When you click on one of those links, you should arrive to about the same type of UI with identical (or at least similar) information available. Getting usage from the menu will enforce (we hope) the coherence of the UI. Actually, if a page is registered to a menu, its usage value gets set from the usage value set on the menu through its ZCML directive. Anyway, usage can be overridden by initializing it through the page configuration (ZCML directive). The values of the 'usage' are chosen to describe broad categories rather than individual templates or elements. These are the proposed values: o 'usage/objectview' is the usage when browsing contents. Example: folder contents. o 'usage/activitydialog' is the usage when you are modifying an object in any way. Example: rename. o 'usage/error' is self-explanatory. o 'usage/addingdialog' is used during the process of adding a new item. Those values must be registered through the <browser:usage name="usagevalue" /> ZCML directive. The following directives share the usage attribute : o browser:menu o browser:view o browser:pages o browser:page o browser:editform o browser:subeditform o browser:editwizard o browser:addform o browser:addwizard o browser:schemadisplay The usage attribute can only be set as one of the registered usage values. As an example, the 'template.pt' master template in the 'rotterdam' skin has the following block:: <div tal:condition="usage/objectview" tal:repeat="structure view/tabs"></div> CONTRIBUTING Please send Zope 3 news, and newsletter suggestions and requests, to gary(a)zope.com, with "Zope 3 newsletter" somewhere in the subject line. As you can see above, both quick and lengthy news items are acceptable and desirable. MORE INFORMATION ON ZOPE 3 The central place to find Zope 3 information is currently http://dev.zope.org/Zope3 The Zope 3 mailing list is archived and managed at http://lists.zope.org/mailman/listinfo/zope3-dev The Zope 3 development IRC channel, #zope3-dev at irc.openprojects.net is (strictly) for discussion of Zope 3 development issues. Newsletters are (supposed to be) archived at http://dev.zope.org/Zope3/Zope3Newsletter

2 1

RE: [Zope-dev] Where did __traceback_info__ go?
by Bjorn Stabell 22 Dec '03

22 Dec '03

Dieter: > Bjorn Stabell wrote at 2003-12-21 23:49 +0800: > >I upgraded to 2.7b3, and it looks quite solid! > > > >I have one problem, though: I can't find the "full tracebacks" that > >include __traceback_info__ anywhere! > > They are not in "http://<yourZope>/error_log"? No, the error, UnicodeError, doesn't even show up in error_log or on STDOUT. It does show up in events.log and on the error page, if I add error_tb to the standard_error_message. Nowhere, however, does the __traceback_info__ information show up. Regards, -- Bjorn

1 0

Where did __traceback_info__ go?
by Bjorn Stabell 21 Dec '03

21 Dec '03

I upgraded to 2.7b3, and it looks quite solid! I have one problem, though: I can't find the "full tracebacks" that include __traceback_info__ anywhere! I used to start up Zope in debug mode, so I'd get everything sent to stdout. Now, stdout just contains some startup stuff; doesn't even contain simple tracebacks. The event log contains tracebacks, but it doesn't contain __traceback_info__. I'm not sure if it contains the __traceback_supplement__ stuff? On a related note, perhaps it would be more clear what got sent to stdout if stdout was just another log handler, and so it could be configured the same way other logs are configured, e.g., <logger event> <stdout> level INFO </stdout> <stderr> level WARN </stderr> </logger> Bye, -- Bjorn

4 3