[Zope-dev] DataSkins containing DataSkins

Phillip J. Eby pje@telecommunity.com
Tue, 07 Nov 2000 10:51:30 -0500


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.