"Phillip J. Eby" wrote:
> Just comment, please, preferably in e-mail via Zope-dev.
> Thanks.

Generally very clear and helpful. Tomorrow, I'll try it out on someone
who hasn't been looking at ZPatterns a great deal, and see what she gets
from it.

A few suggestions. I feel sad that these seem to come across as
criticisms. Really, I'm very glad that you've found some time to work on
more accessible documentation.

You don't seem to say anything like "You make your own domain-specific
classes derive from DataSkin. These can be ZClasses or Python classes".
This may be obvious, but I think it is an important part of how data
skins are intended to be used.

"""A data manager helps data skins by:

Providing them access to their Data Plug-ins, including propagating
transaction events and DataManagementEvents to the Data Plug-ins"""

Still very jagon-filled. That's ok, if it is accompanied by some
real-world explanation.
Perhaps add something like "You can use Data plug-ins for indexing
Dataskins in a catalog, or in many catalogs, or [another different
familiar example]".

"""Keeping track of their canonical or "normalized" forms for
acquisition management"""

You almost lost me there :-)

"""Or, if a data skin is retrieved from any other Zope object, its
__of__ method will try to find a Customizer or "Folder With
Customization Support" in the acquisition path, then ask it for a data
manager to bind with. Once this is done, the skin remains bound to that
manager until the next such occurrence."""

Pretty clear, except the end -- next what occurrence? The next time the
data skin is retrieved from a Zope object? So, every time a dataskin is
retrieved from a zope object (that isn't a Rack), it uses acquisition to
look for a customizer.

Steve Alexander
Software Engineer
Cat-Box limited

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to