[Zope-dev] Re: ZPatterns complexity?

[Phillip J. Eby]

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.