At 11:54 AM 6/27/00 +0400, Jephte CLAIN wrote:
mike wrote:
There is no way to infinite recursion if Rack.getItem is leaved untouched. Ah ah. But people will touch it. Like me for example :-) There is no way to prevent overriding getItem from a ZClass for example. And it *will* recurse infinitely, making Zope dumping core.
getItem/newItem are not a high level methods, they are *part of DataSource's protocol* which *implemented* in Rack with retrieveItem and buddies. getItem/newItem are not meant to be overrided. retrieveItem/createItem are to overrided. This is different level for me.
When Philipp wake up (I guess he's asleep right now :-)), he might give his opinion about that.
I've been on vacation. I'm basically with Mike on this one, with a slight amplification on my intention here. IMHO, what you should be doing with your SQL is making it an AttributeProvider, and using the "virtual" mode of the Rack which does not store the item in the ZODB, only its propertysheets. Then you will not need to override *anything* in any of the ZPatterns classes. If you need to store persistent attributes, this may be an issue. I'm planning to create a "Persistent External Attribute Provider" to allow one to store attributes persistently even when the object itself isn't stored in the ZODB. In any case, my intention for mixed-database objects in racks is that one should not need to override any of the built-in methods of Rack. In earlier versions of ZPatterns, such overriding seemed like it would be necessary, but as of 0.4 there is really no reason at the framework level to mess with any of Rack's implementation details unless you need to create a special hand-tuned version for some critical bit of efficiency. Almost anything you could do by overriding those methods can now be done through Generic Attribute Providers or other plug-ins.