At 05:39 PM 11/6/00 -0800, John Eikenberry wrote:

The base DataSkin will be in a Rack. Would there be any issues in making the embedded DataSkins (contained on the base DataSkins) use this Rack as well? Seems like it might result in the confusion about which DataSkin a PlugIn on the Rack worked with.

Yes, it would, if you persistently stored the DataSkins in the other DataSkins. If you use an Attribute Provider, however, that loads them from a different Specialist+Rack, you'd be fine.

Would it be better to use Customizers in some way... either have the base Dataskin or perhaps the Specialist also inherit from the Customizer?

Ugh. Well, you might be able to make the DataSkin a Folder w/Customization Support... but I don't know if it would work. I've never tried mixing a DataSkin with the classes that support DataSkins. I think there might be some horrible method naming conflicts.

Phillip, I think you've considered this (didn't you once mention converting PropertySheets to DataSkins). What issues do you think I should be aware of in planning for this.

Doing DataSkin propertysheets would be done by having the propertysheets come from a different Specialist. Thing is, if you want to store DataSkins arbitrarily nested within one another, you can do it in the regular Zope management structure, without using a Specialist/Rack combo. On the other hand, if you have a structured nesting, (e.g. object type A contains some number of object type B), then you should be using attribute providers/SkinScript to define how those sub-objects get stored. To use ZPatterns for its intended purpose, it is critical that you step back and NOT think in terms of how you'd implement a solution in Zope without ZPatterns. In fact, it is important that you not think of implementation *at all*, because it will distract you from the real question, which is how to segment the responsibilities of your application. Once those responsibilities are segmented, implementation is simply a matter of writing the necessary methods and SkinScript. In this case, segmenting according to the RIPP model means that objects are never truly "contained" in other objects. An object just gives you ways to get at related objects. And if there is a relationship between objects, that means that the object on the "other end" of the relationship plays some role in your system, and where there's a role there almost always needs to be a Specialist. Now, it may seem that this is needlessly constraining, because it is more restrictive than Zope. After all, Zope lets you put anything in anything -- just like Basic lets you go to any line in the program. :) ZPatterns, however, exists to make interconnectable frameworks possible. You can still do the kinds of things Zope can, but you must explicitly think through your application's role model, and seperate the responsibilities accordingly. The payoff of this more rigorous design approach is that your application can be backed by *anything* that can support the data, including combinations of different kinds of data stores. And, your application will be a potentially re-usable framework.