Last Build Date: Sat, 11 Jan 2003 19:24:29 GMTCopyright: Copyright 2003 Jeffrey P Shell
Sat, 11 Jan 2003 19:24:27 GMTIndustrie Toulouse has moved to A new home (toulouse.amber.org) and a new publishing system. Most of the archives will be there soon. The Radio site will remain up indefintely, but no new content will appear here.
Thu, 09 Jan 2003 21:37:38 GMTEuroPython had an interview with Jim Fulton (I can't determine the date, but I'm guessing some time within the past year), in which he gives a good summary of Zope 3's differences over Zope 2 (I've been looking for such a summary):
Zope 3 moves Zope from an inheritance-based framework to a component-based framework. Complexity is managed by splitting responsabilities among many cooperating components, rather than many cooperating mix-in classes. Components are connected using interfaces, which also provide component specification and documentation. Some other big ideas:"Cooperating components instead of cooperating classes" could still be seen as an ambiguous phrase. I think developers who are steeped in component models and aggregation would understand it. But what about those who are used to the static overbearing inheritance model? I guess it could be summed up as "Zope 2 excepts you (you being an object in the Zope system) to provide it lots of information and functionality all by yourself. Zope 3 looks for people to help you". In Zope 2, if you got annoyed that a particular didn't implement the obscure little method to display sizing information in the ZMI, there wasn't much you could do about it without monkey patching. In Zope 3, you write an adapter for that object that implements the ISized interface, register the adapter, and voila! One little object helping another. By developing services to query for adapters (saying "I've got Frank here, can anyone tell me how tall he is?") instead of expecting behavior directly from an object, new doors to interoperability and speciality open up. Susie pops over and says "Why I can tell you, I've got measuring tape right here! He's 5 feet, 11 inches tall." Of course, Frank can say "I can tell you" and report his tallness himself, but he's a busy man and knowing his height at all times just might not be something he needs to do on a daily basis. Of course, if Susie can be replaced with a robot or some other machine or person that can perform the same job (measure how tall people are), she can be replaced without bringing down the system. Frank's genetic algorithm can't be replaced (easily), so if he's suddenly unable to report his height correctly, he's useless in this situation without someone to help him adapt. Hmm.
I could go on, but I won't.
- It should be possible to use existing Python objects in Zope with little or no change.
- Applications can be customized by adding, changing, or removing components.
- Site configuration is done by site-managers or deployment specialists without modifying code.
- Many CMF technologies will be part of the core.
- Acquisition and namespace lookup is wildly more explicit.
Thu, 09 Jan 2003 19:41:15 GMTI'm generally liking Apple's new Safari web browser. I think it will actually open up some interesting competition in the Mac OS X browser world, at least between Safari and the Mac OS X native Gecko browser, Chimera. There's already been a lot of talk about Safari, these are just a couple of links and downloads that have stuck out for me:
Tue, 07 Jan 2003 20:10:01 GMTGood MacWorld. A curious non-announcement - Apple's X11 for Mac OS X public beta. I love that new 12" PowerBook. If I can ever find it in my heart to replace my beloved white iBook, it will be with that. Right now, this 500Mhz G3 is suiting me fine, but to have a full PowerBook with a PC card slot and audio input!, that would be sweet. Now if only Pro Tools 6 Free would come out (I still haven't heard if they'll continue that program), and Supercollider 3 would come out. Well, I guess I could always go over to the other side and check out Max/MSP's beta for Mac OS X.
Mon, 06 Jan 2003 02:08:13 GMTVolkswagen's advertising team delivers another beautiful commercial for the New Beetle Convertible.
Sat, 04 Jan 2003 18:53:11 GMT
With Zope 3X alpha 1 out, I decided it was time to jump in again and see how it would be to write a new content object for it with associated components (adapters, views). I've tried to include comments in the files and README to document what I was doing as I was going along.
The current release is intended to focus more on documenting how to write a new content component for Zope 3 than on being a smart reStructuredText client. That functionality may come later.
Fri, 03 Jan 2003 22:22:33 GMTTwo big alpha releases were made for the new year: Python 2.3a1 and Zope 3X a1. Python 2.3 doesn't make any major changes to the language (unlike previous Python 2 series releases, which brought things like list comprehensions, generators, nested scopes, iterators, etc). Andrew Kuchling, as always, covers the changes extensively. Of interest are - ability to import from .zip files, universal newline support!, a new logging package, a new Set datatype and default Boolean datatype. Zope 3X (x for "experimental" - a final Zope 3 release without the 'X' is expected to have some Zope 2 migration features) is a completely different beast from its ancestors. Its primary focus is still the Object Publishing mission that's been in place since the days of Bobo, but beneath the covers it is shockingly different from Zope's 1 and 2 before it. Zope 3 is also dubbed the component architecture project. Its design focuses on many interacting components with well-defined interfaces. It's an aggregation heavy design, as opposed to the inheritance heavy design of Zope 2. Adapters exist to take the burden off of objects for out-of-scope elements such as text indexing or sorting-by-size. As the author of a particular object, you can implement those interfaces (ISearchableText, ISized) on the class itself, or as separate classes. Code that requires searchable text or sizing information asks for an ISearchableText implementation for your class, and since that's the only interface that it's expecting to use, it doesn't matter if it gets an adapter or your class - it only matters that the ISearchableText interface is implemented correctly. Design by Contract finally makes a strong appearance in the Zope world. Zope 3 should also score big on the packaging and deployment front. Zope 3 uses a new configuration language called ZCML. ZCML is used to register new components at load time, and to load in still further components. It wrests control away from Python's import statements and need for special functions in __init__.py such as the common Zope 2 initialize(context). As such, it can be not only more expressive, but allows control over the order in which items get initialized. Under the mantra of explicit is better than implicit, all new components have to be explicitly added (usually in the products.zcml file). A side effect of this is that heavily customized Zope distributions can be made. Some such distributions exist now with Plone installers and BizarShop. Zope 3's customization and configuration capabilities should allow similar distributions to be made that don't look like Zope at all, while still tying in to all of the available features of Zope. The combination of heavy Interface use combined with rich configuration options should mean that any part of the system could be kicked out in place of a new one, as long as the expected interfaces are implemented. This is a fundamental feature of component systems, and Zope 3 looks like it will live up to this feature. Another big feature of Zope 3 is the proliferation of View Components. Views can be individual ZPT pages, attached to a particular content interface via ZCML. But they can also be full-on components in their own right, usually as Python classes. And they're not limited to HTML. Other views may be written to correspond with the other publishing channels (ftp, xml-rpc, and others in the future). I wrote a post back in September about my early experiments augmenting other Zope 3 components, in which I include some example code making an XML-RPC view onto a Job Board component written by someone else. My final paragraph in that post reads: And finally, Zope 3 should yield a usable scalable means of adapting the works of other developers into new solutions by providing better control of product/service/view configuration and overrides, such as adding a new XML-RPC API to someone elses bug tra[...]
Sat, 28 Dec 2002 08:01:38 GMTIt should come as no surprise that I'm still fiddling with project management solutions via Zope. I've started down a new path, but before I explain it, I want to explain the current situation. General Requirements We're a very small organization (two people, with loose associations to other very small organizations). As such, we're constantly busy (thankfully) and don't have too much overhead to worry about in regards to project management. But having a to-do list of any sort is always helpful, and having a place to dump notes and flesh out ideas is always good too. Plus, we're decentralized - we work as much from home as we do from the office, and are often working from multiple machines in either location. Sometimes we need to communicate progress with each other, sometimes it's nice just to have a list for our own uses. Ideally, content (which could be proposals, notes, software configuration requirements, etc) and issues should be managed by the same system - or at the very least be close to each other. And projects need to be easy to add in to the system by either main user, from wherever they may be. And most of all - it should offer only just-enough project content management features. What we've used Last year, we experimented with a couple of home-grown systems. One was a Zope based SQL backed project / task / contact tracking system. Data went derelict rather quickly. I was working on a much more thorough CMF based system with detailed workflows, nested tasks, role assignment, and more. There were a few key features that were difficult to do to meet our requirements, particularly in the non-containment object relation area, an area where Zope has typically struggled (but should be dealt with in Zope 3). We gave the Roundup (0.4.2) issue tracker a try. While fast, it was still a young product. Too much command line work was involved to set up a Roundup instance, and while there is a Zope-Roundup Gateway available, it didn't integrate too well with Zope based content. I really like Roundup and think it has a lot of potential, but it didn't satisfy our requirements. Ultimately, we landed in the ZWiki 0.7 + Tracker situation. Each project was their own folder or wiki, and usually had a tracker in it. This approach succeeded on the simplicity category and has been used for almost half a year. But it suffers from a couple of problems. The first is that Tracker is an aging old beast. It's generally pretty thorough, but has some rough edges. It's no longer supported, and I've heard claims that it doesn't work with the latest Zope release family (2.6.x). The second problem is that I'm no big fan of Wiki's. I never have been. They've been useful, but we don't need whatever supposed collaborative effects Wikis are supposed to have. I don't like Wiki names - they either end up looking funny (with words like OneDotOh or ZoPe) or kick in when you don't want them to. Now that I've done some work with reStructuredText, I've come to loath working with Zope's normal StructuredText. It just doesn't work well with TextAreas. If you're used to Zope's StructuredText and have a good editor on your side, it's not too bad. But StructuredText and DTML (outside of SQL methods and occasional small non-HTML uses) are two Zope technologies I'm happy to leave to the past. Finally, we needed a stronger content management system than a pool of individual wiki's provided. We did (briefly) try out ZWiki 0.12 with setting up the ZWiki based Issue Tracker, but it was a beast to set up and configure (loosing out on the 'easy-to-add-new-project' requirement) and too dependant on DTML for me to debug and make work for us on short notice. I liked the integration of Issue Tracking with the Wiki (gaining points on the keeping-issues-close-to-content) but there was too much pain involved, and too much inolvement with the technologies I wanted to leave behind[...]