At 01:40 PM 6/2/00 +0800, Mike wrote:
As I'm reading ZPatterns source code more and more I'm finding there are good things just hidden in unclean or bad defined interfaces. Just a suggestion: define interfaces as abstract classes first, then implement them (as AbstractRack, DefaultRack and GenericRack for example).
I might back interfaces out later. But while the whole thing is still a prototype it doesn't make a lot of sense to keep two going. Originally, Rack itself was a base class, but the way things are shaping up it will only need subclassing if you want a custom way of mapping from a mountable's "id" to the persistent data stored by the Rack.
told 'mess' I meant I spent a lot of time to realize the Rack do not store RackMountables but just manages them.
That was the whole point of Rack; this has been mostly addressed on the mailing list, in my talk/slides at the Python conference, and in the ZPatterns wiki.
The second thing confusing me is property sheets. They come from problem domain isn't it? I guess attribute providers are sufficient to do all the work. What that sheets needed for?
Two things. 1) WebDAV support requires the ability to add arbitrary property sheets containing arbitrary data. 2) Propertysheets (especially when used with XML namespace URL's) give a way of standardizing an interface to common properties, without polluting an object's "main" namespace. This way, one can take an object that wasn't designed for a certain purpose, and attach a propertysheet that serves as an adapter to give it a different interface to its data. Consider the scenario of a scheduling application that creates calendars, or manages resource contention. But you would like to use it with say, a "room" object that was not written as part of the scheduling application. If the scheduling application can just add a scheduling propertysheet to the room object, or you can configure the room objects' datamanager or rack to add a propertysheet that makes it usable with the scheduling application, then you get to benefit from two unrelated frameworks (room management and scheduling). This is a core intent of ZPatterns: making it easy to blend frameworks that cover different behavioral aspects and problem domains. Because real world objects have a funny way of being part of more than one "problem domain" from a software development point of view. :)
And one more thing I would to say. I agree the RackMountable should not be acquisition-aware because Attribute providers have full responsibility on its (acquired) attributes. But I do not like default Specialist.__bobo_traverse__ behavior. It is trying to make __of__ on thing which is not an Acquisition.Implicit by definition!
Good point. __of__, however, is not limited only to acquisition. In any case, I have moved the __of__ call to the Specialist.getItem() method in 0.4.0. In 0.4.0 DataSkins (the replacement for RackMountables) include an __of__ method in their base class, as this is where they figure out their controlling DataManager (when retrieved from something other than a Rack). Thus, with 0.4.0 it is not necessary to include Acquisition.Implicit in a RackMountable's base classes.