WELCOME TO THE ZOPE 3 NEWSLETTER: ISSUE 10 (5 SEPTEMBER 2003) Welcome to the tenth 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: - Be sure to read Stephan's release management news item, below. - Next "geddon" (big change to Zope 3, a la Armageddon) appears likely to be container-geddon, which in part is a parent- or context-wrapper-geddon. In a big move from Zope 2 approaches, Zope 3 will not rely on context wrappers in the default configuration. Objects stored in the Zope 3 ZODB will either implement an interface that allows their immediate parent to be stored as a reference, or be adaptable to a persistent wrapper that implements this behavior. The advantage is expected to be that references to other objects in the system can be much more Pythonic--foregoing storing paths in favor of actually storing the Python object references. This should greatly simplify writing local services and other context- and Zope-aware machinery. The disadvantage for some applications is that objects can then only have one traversal parent, and thus only one traversal path. This limitation is expected to be mitigated, as necessary, with alternate configurations using context wrappers (which will still be available) or with other mechanisms such as proxies. Questions or concerns? See http://dev.zope.org/Zope3/ParentGeddon or the other resources listed at the bottom of the newsletter! PHILIPP VON WEITERSHAUSEN: ZCMLGeddon Jim's ZCMLGeddon had finally landed, so Stephan and I went through the complete source tree and converted all directives using schemas. The biggest benefit was that user strings in configuration (like titles or descriptions) are translated now. Other benefits are better extensibility, override support and cleaner meta-configuration code. I also made an attempt to get XML schema interfaces working again (support for it had to be dropped temporarily in order to advance with ZCML geddon). While I succeeded in doing that, my changes are slowly rotting in zcml-interface-field-branch. I had to do it in a branch since the change involved a few hard-wirings in zope.app which I wanted Jim to look at. Unfortunately, he was very busy with ParentGeddon at the time. i18n Now that we had quite a few MessageIDs coming from ZCML, it only made sense to go through the python code and internationalize it. Fortunately, Stephan took on that part. However, I was happy to help him translate all of Zope3 to German, once his work was done. I have also started translating it to Spanish, but as I am not a native speaker, help from someone who is would be greatly appreciated. Sidnei da Silva and Godefroid Chappelle started translations for Brazilian Portuguese and French, respectively. i18n and ZCML While translating, I found that a few English words like "View" or "Change" are ambiguous when used without a context. For example, "View" could both mean a view component or the "View" permission. While (sadly) one word applies to them in English, the contrary is the case in most other languages. While Stephan first argued for different i18n domains, like zope_components, zope_permissions etc. (we currently have everything under one domain, zope), him, Fred and I came to the conclusion that using explicit MessageIDs was the better solution. While both python and TAL support setting explicitly MessageIDs, ZCML's i18n machinery didn't so far. For a directive such as:: <permission id="zope.View" title="View" /> I proposed the following syntax:: <permission id="zope.View" title="[view-permission] View" /> Martijn Faassen and Godefroid Chapelle rejected this idea, mainly because it created a new syntax and was incoherent to TAL's i18n support. Their suggestion was to be coherent with TAL and use i18n:attributes. Stephan and I however argued that a) ZCML isn't TAL b) namespaces have a different connotation in ZCML c) i18n is currently not part of the core ZCML machinery -- should it be? d) it would thus require major changes to the ZCML machinery -- again! The discussion drifted slowly away from the main issue (i18n) into a general ZCML discussion which is still going on. Shane Hathaway expressed his general doubts on ZCML usability and Martijn announced he will put some effort in studying ZCML's current usage and try to come up with improvements. While we appreciated this rich input concerning ZCML (even though it came *after* ZCML geddon), Stephan and I needed a fix for our original i18n problem, so we went ahead and implemented my proposal. It seems the issue remains open. We are glad to have a fix for the problem now, but we surely appreciate suggestions on how to solve it in a more elegant way. Unused imports Having found many unused imports during ZCMLGeddon and the following i18n work, I took an hour to mock up Martijn's importchecker tool to produce grep-style output. The benefit is not only better readability of the output (above all: line numbers) but it means that Emacs now understands its output, making it a lot easier actually removing all of those unused imports. After I had successfully removed all unused imports from Zope3, I contributed my patch to Martijn. He promised to revise the code and make a release asap. FRED DRAKE: Improved security for zsync checkouts The "zsync" client for Zope's filesystem synchronization support now makes it easier to separate authentication data from a checked-out copy of objects in Zope's database. New "login" and "logout" commands, modeled on those of CVS, allow authentication tokens to be stored in a persistent cache separate from a checkout. This can be used to avoid storing the password as part of the URL used to check out an object tree. For example, to check out a portion of a Zope site without storing the password in the tree, "log in" to the site and then perform the checkout:: % zsync login -u username http://example.com/ Password for username at example.com: % zsync checkout http://username@example.com/some/directory/ ... If *user* or *url* are omitted, the values are selected from an existing checkout in the current directory, if any. If there is no checkout in the current directory but *url* is given, the user will be prompted for *user* interactively. The only information used from the URL are the protocol scheme (HTTP or HTTPS), the host and port, and the username. The "logout" command removes an authentication token from the persistent cache. ANTHONY BAXTER: A Zope 3 Catalog! As part of the Melbourne sprint, the catalog was implemented and hooked up to the existing indexes. There's both content-space and utility space catalogs. There's a simple query interface provided, and the catalogs participate in the ObjectHub. There was also some refactoring of indexes to start pulling out common code - there's a bunch more to do on this, though. STEPHAN RICHTER: I18n and TAL When internationalizing Zope 3 , we ran into some bugs with TAL's I18n support. Thanks to Godefroid and Fred these are fixed now and backported into Zope 2.7.0. After having actually worked with the Zope 3 I18n support by translating Zope 3 itself, I am proud to say that Zope 3's I18n is superior to many other systems I have seen. We also fixed up the extraction tool to be much more flexible and to support explicit message ids better. Phillips section has more on that. Python <script> support in TAL I finally got around implementing a TAL "script" attribute to work. The support was mainly written for scripters to give them a better entry point to Zope 3. Here an example of what you can do: <script type="text/server-python"> print "Hello World!" </script> and <p tal:script="text/server-python"> print "Hello World!" </p> A more elaborate example would be: <html><body> <script type="text/server-python"> global x x = "Hello World!" </script> <b tal:content="x" /> </body></html> This support is currently only available in "Templated Pages" after you activate the hook using the "Inline Code" screen. TTW Development After Sidnei implemented "Mutable Schemas", I started work on (and finished) a schema-based Content Component type for TTW development. Coming from the user's point of view we also implemented a local Browser Menu Service, which allows you to create new menus and menu items. Here is what you can do now in a package: 1. Create a Utility Service. 2. Create a Menu Service 4. Create a Persistent Schema Utility (this begs to be renamed). Call it 'IDocument'. Add some fields. 5. Create a Content Component Definition. Call it 'Document'. Find the IDocument schema and set it to the definitions schema. Make security assertions as desired. If you like, you can also adjust the menu entry. 6. Go to your Content space. There you should see a 'Document' object in the list of available Content Objects. As usual, click on it to create the object. 7. Creating custom views is easy too. Go back to the default package. Create a Page Folder. Tell it to provide views for 'IDocument'. Create a view and register it with the local Browser Menu Service. Documentation After a long break, I started working on the Developer's Cookbook again by committing the 'SmileyService' into 'zopeproducts/demo'. The first chapter on how to write the global version of the service is already online; the local implementation recipe will follow soon. zope3.org While I made much less progress than anticipated, we made some great progress this week. I finally got the access I need to the box (thanks to Matt Kromer), so that I will be able to get the Web Server ready. I also plan to install the z3-checkins product. Other than that, I got a lot of valuable usability feedback from Fred and Jim about the bug tracker, which I all incorporated in the latest checkins. Finally, Jim and I worked on a change password screen for Zope 3, which ended up being a major refactoring and will be checked by Jim soon. It will also provide a basis for general user preferences. Zope 3 Release Management As you may know, I visited Jim in Fredericksburg last week. Instead of having a mini-sprint with lots of coding going on, we purely concentrated on the Zope 3 Project Management side and writing up Proposals about some of the new ideas. Overall, we created 5 or 6 proposals, several bug tracker entries and I got a good overview of the outstanding tasks. Furthermore we discussed the Roadmap in great detail. Here I will only state the summary. For more details in the future, you should see http://www.zope3.org:8080/++skin++tracker/tracker/1/%40%40dependencies.html Summary: There will be a MS4 release that contains all the "geddons" in progress right now. I hope that we will not need any more geddons after MS4, since we will work towards the beta. Even though the release date really depends on the community involvement, I think it is unrealistic to expect that release before mid-October 2003. From then on everything should be downhill and Zope 3 can become more open to other developers as the core API stabilizes and rough corners are smoothened out. The first beta will be released once the fundamental application components are settled. I also hope that some major UI work will become visible before the first beta. A wild guess for a release date would be mid-December 2003. Beta 2 will represents further work on the UI and concentrating on making Zope 3 a good development environment by removing last quirks. Based on the UI work being done, this might be the last beta. If, however, UI work does not start before Beta 1, we will have a Beta 3 that concentrates on UI polishing. After that we will gear towards a 1.0 release. Call for Information Architects and Graphic Designers As stated in the section above, a lot of the upcoming progress of Zope 3 will depend on the improvements to the Web user interface. Currently no-one feels responsible about the GUI and you certainly do not want the developers doing this work! Do you? So please step forward and help us build a great UI. You do not even need to know Zope 3 or Zope in general. If you are interested, send a mail to zope3-dev@zope.org and we will get you started. CONTRIBUTING Please send Zope 3 news, and newsletter suggestions and requests, to gary@zope.com, with "Zope 3 newsletter" somewhere in the subject line. As you can see above, casual and quick news items are acceptable and even 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 occasionally archived at http://dev.zope.org/Zope3/Zope3Newsletter