WELCOME TO THE ZOPE 3 MINI-NEWSLETTER: ISSUE 3 (13 NOV 2002) Find out what's going on in Zope 3 development, then contribute your opinions, your experience, and your code to one of the most exciting Open Source projects going. Most news is submitted. Tell us what you're doing! Send anything from a sentence to a few paragraphs about your latest efforts, be they code, documentation, research, or design, to gary@zope.com. I'll send one of these out whenever we have enough to warrant it-- just two or three submissions are enough--and I'll also specifically request news from the zope3-dev@zope.org group once a month. I send them to zope@zope.org and zope3-dev@zope.org (subscribe at http://www.zope.org/Resources/MailingLists), announce it on the front page of zope.org, and archive it at http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Newsle... LITE 'N' EASY GLOSSARY: Each newsletter begins with a high-level glossary that might help you understand a bit about what's going on with some of the announcements. Want to help others get a grasp on your favorite Zope 3 (or pertinent Zope 2) concept? Send in a definition, or request one, or fix these. Starred (or italicized) items have definitions also in the glossary. Only terms discussed in this newsletter or newly submitted or corrected terms are included here. For full glossary, see http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewsletterG... This glossary contains a number of corrected definitions from the last newsletter that are otherwise not pertinent to the news--blame the editor! :-) [PRELIMINARY, from Steve Alexander] CachingService: Right now, the caching service is for caching data so that the cache is common to all the threads in Zope. An example of data cached like this would be the results of calling an SQL method. Different cache implementations can be plugged into the Caching service. Currently, there is one implementation that works like the Zope2 Ram Cache Manager. The scope and functionality of this service is under development. [CORRECTED] Placeful: An adjective describing an object that has a *traversal context* in Zope. For example, an object is placeful if it can be reached by traversing a URI path, be it "/myObject", "/myFolder/myObject", "/myFolder/myNonZODBConnection/myObject", or "/++etc++Services/Packages/default/myErrorService" (the last example is a hypothetical *placeful service*). More technically, these objects are wrapped, mostly invisibly, with one or more "Zope.ContextWrapper"s, which provide the ability to get contextual information similar to aq_parent etc. in Zope 2; moreover, following these nested wrappers to their ultimate (top or root) context must reach the top (root) Zope object (i.e., the object found by traversing the path "/"). Note that the correct usage of context wrappers should actually use the methods in Zope.Proxy.ContextWrapper, which also provide and handle security proxies. Opposite of *placeless*. [PART OF PLACEFUL CORRECTION] Placeful Service: a *service* that is *placeful* and is pertinent only to the Zope traversal branch (or "folder" and all children) in which it resides. This usually means that the service resides in the *ZODB* (and so is *persistent*). Similar to standard programming "local" concept of variables in that a placeful service's scope is restricted, where the scope in this case is the scope of a traversal branch. A placeful service is usually obtained by using a traversal context: in Python, after importing Zope.ComponentArchitecture.getService, one would use 'getService(myTraversalContext, "Events")' to get a placeful event service, where myTraversalContext is another placeful object. Note that if a placeless event service is not installed within the traversal context, a *placeless service*, if such exists with the requested name (such as "Events"), will be returned. Opposite of *placeless service*. [CORRECTED] Placeless: An adjective describing an object that does not have a traversal context, and usually is not intended to have one. This usually means that one cannot traverse to such an object via any URL path, for instance. Technically, it also means that these objects do not have nested "Zope.ContextWrapper"s that resolve eventually and finally to the root Zope object (i.e., URI path "/") and, in fact, in all to almost all cases, means that they do not have any ContextWrappers at all. Opposite of *placeful*. [PART OF PLACEFUL CORRECTION] Placeless Service: a *service* that is *placeless* and is available to any object. This usually means that it does not reside in the *ZODB* and is not *persistent*--connections to placeless services, therefore, usually must be made on every Zope startup, and are often controlled through *ZCML*. Somewhat similar to standard programming "global" concept of variables, in that they are not restricted by any scope, where scope in this case is the scope of traversal context (that is, the context of where an object is found in Zope via URI path). A placeless service can be obtained (if one by the requested name is installed) in Python by importing Zope.ComponentArchitecture.getService and then calling "getService(None, 'Events')"--that is, the traversal context (first argument) is None. Opposite of Placeful. [REPEAT] ZCML: Zope Configuration Meta Language. The XML language that is the file-system configuration tool for site administrators. One uses it to declare new Zope 3 products, new services, new views, and so on. NEWS SNIPPETS: * Jim Fulton wrote a preliminary Zope 3 roadmap: see http://cvs.zope.org/Zope3/doc/ROADMAP.txt?rev=HEAD&content-type=text/vnd.vie... This is maintained by Godefroid Chapelle and Tom Deprez. If you head a project on Zope 3 and have not yet contacted Godefroid or Tom with information about where your Zope3 job is situated, what the status is (level of completeness) and, briefly, what the project's definition is, please do so when you can. * Many of the news snippets are covered in Martijn's discussion below. Workflow and UI got particular attention in the mailing list lately. MARTIJN FAASSEN: Infrae Content Management Sprintathon Update The Infrae Sprintathon in Rotterdam, the Netherlands, will have about 30 developers present (if everybody makes it). This is great! It's also a rather dauntingly large number. We've stopped taking applications; you can still try (mail faassen@infrae.com) but you'd better have a very convincing reason on why you should be joining us (for instance, you work for Zope Corporation). Having such a large amount of developers present means the preparation needs to be very good, so that we won't waste precious time at the event itself and avoid utter chaos. We're going to be strict about this, so do read the wiki page about this here: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintPre... We have several project teams and not everybody has joined a project yet. So hurry and join one -- here's the hype! * Workflow. The very active workflow team seems to be full of workflow gurus; they seem to be writing their fourth workflow system or so. If you're not a guru then this may be a great opportunity to learn more about workflow! http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintWor... * Documentation. The documentation project will be working on providing stand-alone narrative documentation for Zope 3 developers. Writing documentation is a great opportunity to learn more about the way Zope 3 works. It is also a good opportunity to influence the design of Zope 3 by writing what Jim calls "science fiction" documentation -- documentation of code that does not yet exist. The documentation project also has an interest in generating documentation from the current codebase. http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintDoc... * Searching. Struggling with the ZCatalog in Zope 2? Think there should be a better way? Here's your opportunity to make your life better in Zope 3. EventService! ObjectHub! Learn more about them and improve life for future generations. http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintSea... * User Interface. Everybody likes to talk about it. Everybody has ideas. The User Interface project will be laying the groundwork and will actually do something about it. Join user interface experts in our user interface team! http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintUse... * User Management. Zope 2's user management system is, out of the box, rather simple. In order to really do something you need to install one of the many extension products. Now the challenge is to take the lessons learned from these and build a solid foundation for user management in Zope 3. A concrete get-your-hands-dirty project. http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintUse... For regular updates see the main page about the sprintathon: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/InfraeSprin... The CodeWorksSprint in Vilnius, Lithuania will be held in the week after the InfraeSprintathon. Several people present at the sprintathon will be at this sprint as well, including Jim Fulton. See this page for more information: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CodeWorksSp... STEVE ALEXANDER: Logger, cache manager, and bug fixing I fixed up the components that log http and ftp requests: the interface and implementations were out of synch. I've been helping CodeWorks out with their CacheManager work. Brad at CodeWorks found a curious security bug, which we tracked down to some problems in ZopeSecurityPolicy, and successfully fixed. R. DAVID MURRAY: ZCML documentation, doc tools, and polish I checked in my changes to Zope.Configuration (the zcml parser) to allow directives and attributes to have description strings attached in the meta.zcml files, and a utility to extract those descriptions into structured text files following the format laid down by Steve Alexander in the doc/zcml/namespaces.zope.org documentation. Now all we have to do is get all the meta.zcml files updated to include descriptions. The doc tool (makezcmldocs) prints error messages to stdout if a directive or attribute doesn't have a doc string (it tries to guess the directory the directive is defined in; most of the time it gets it right). I'll work on adding proper description strings as I learn various modules, but it's a non-trivial job and help would be welcome. Take a look at Zope.App.ContentDirective/meta.zcml for an example (or the first part of doc/zcml/meta.stx). Note: if you change a meta.zcml file over to the "new style", you will probably have to update the module's tests by inserting XMLConfig('metameta.zcml',Zope.Configuration)() before the corresponding line in the unit test setUp that loads the module's own meta.zcml file. After a mailing list discussion, I also simplified the Zope.Configuration by eliminating the top level 'directive' directive. Directive definitions now *must* be enclosed in a 'directives' markup. This is how all the existing zcml was written anyway. NEWS CONTRIBUTION GUIDELINES: We want to know what you're doing, be it code or design, so just write something quick and easy. First person and casual is fine, as you can see. Send to gary@zope.com whenever the spirit moves you. LEARN MORE ABOUT ZOPE 3: See http://lists.zope.org/mailman/listinfo/zope3-dev See http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage but be aware the design docs often lag as we develop prototypes. Again, these newsletters and the compiled glossary are archived at http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Newsle...