ZPatterns 0.4.0 alpha 1 has been uploaded to zope.org. No new docs, but README, TODO, and CHANGES have been updated since last week's snapshot. This is now in more or less stable form for this revision cycle; it's labelled alpha mainly because regression testing has been minimal. Some highlights of additions since the snapshot: * DataSkins now work for everything but cut/paste (and that should work under Zope 2.2, although I haven't verified it yet). They do work for copy/paste, and you can make a Folder DataSkin just by blending the two classes in a ZClass w/no additional work. * Generic Triggers have been added. They let you call an arbitrary Python expression (using DTML's safe eval) at transaction commit time in response to an object being added, changed, or deleted. In the expression namespace, you have a CHANGED_ATTRS() function you can call for a list of attributes set or deleted during the transaction, and a CHANGED('varname') function you can use to verify whether a particular attribute was changed/deleted. Generic triggers will also save the "before" values of arbitrary expressions on the object from "before" it changed or was deleted, and provides these before values as attributes of an object called "OLD". Generic triggers have only been lightly tested, but if they work correctly, they should let you do things such as catalog items in a ZCatalog without subclassing CatalogAware and without blindly using the recatalog function. You can also specify that certain attributes will be handled by the trigger, in which case any set/delete operations will be cached, and the trigger can access the new values from the object at transaction/subtransaction commit time, and do whatever's necessary to save those values in SQL, LDAP, or another system of your choosing. * Runtime extensibility - DataSkins look for a class_default_for_x attribute when they don't have an attribute "x" available from their Providers. This allows you to define default implementations of methods, for example, and override them with a Customizer. This really needs a ClassExtender AttributeProvider to be really useful, but you could get by with a Generic Attribute Provider if you had to. These are probably the main new features of interest in 0.4.0, which is now feature-complete in its framework. Next on my list are more plugins (such as ClassExtender), a SkinScript/ASL compiler, and of course, more docs. Future ZPatterns releases will soon be switched to Zope 2.2 as a development system, as the new help system, transactions, path traversal, security API, and other features are very compelling for continued advancements in ZPatterns. (Not to mention that trying to write code that works on both 2.2 and 2.1.x is a royal pain.) Last, but not least, I hope that Jim's new persistent __get/set/delattr__ method support will let me ditch DynPersist.c and let people using binary installs avoid having to compile something special to run ZPatterns. If you're using any previous version of ZPatterns, please check the CHANGES file in this release for notes on compatibility with future versions. I had to use a __setstate__ hack in this release to upgrade older data structures, and certain classes are going to be phased out. I am satisfied at this point, however, with the overall structure of ZPatterns, and should be able to avoid any further upheavals. (Crossing fingers.) Please also see the TODO file for known issues relating to current limitations of the fancy new features, especially on Zope 2.1.x. 0.4.0 will probably have some minor numbering upgrades as I add plugins, docs, and SkinScript. The next big upgrade after that will be work for the 0.5.0 series - indexing, searching, joining result sets across disparate data sources, that sort of thing. I haven't even begun that yet, so no promises on what capabilities will actually result, or when they will materialize. As far as I'm concerned, the 0.4.0 series is complete enough to build useful applications on, and I plan for my team to start doing that ASAP. In the process, we'll probably find and fix bugs, but it will help if I can get any bug reports y'all might have from playing with it. Ty should be releasing a LoginManager 0.8.7 patch release soon to address compatibility with 0.4.0. There are only a few minor changes needed, one having to do with the way LoginManager gets some of its tabs from Specialist, and two changes for RackMountable->DataSkin compatibility. They've been done, but not yet tested or packaged for release.

At 04:22 PM 6/11/00 -0400, Kevin Dangoor wrote:

What will be the right way to subclass ObjectManager? CatalogAware won't really be necessary, because you can use the events stuff to catalog things... but, I make a lot of things ObjectManagers...

All that's required is that manage_afterAdd call self._objectAdding() and manage_beforeDelete call self._objectDeleting(). See DataSkins.py for an example in the DataSkin base class. As for what the right way to get this to happen in ZClasses (apart from creating a Python base), I haven't the foggiest. So, in the code I'm working on now, I've revised DataSkin's implementation of these methods to call ObjectManager's implementation, as long as the skin's aq_base has an objectValues method. This ought to work safely with any kind of object. I'll have to try it out though, to be sure. Perhaps you'll see it in snapshot 2 (if there is one before the final release). In any case, my goal is that all you ever need to do to make a DataSkin ZClass should be to put DataSkin first in the base class list. About the only real limitation would be that you mustn't overwrite the default __init__ method with something that isn't specifically written for DataSkins support.