Phillip J. Eby wrote:

> If I can offer a suggestion...  


> It sounds to me like you don't need SheetProviders at all, if you
> effectively define the property sheets as part of your class, and make
> the attributes direct attributes on the DataSkin.  You then need only set

Ok, I'm feeling pretty stupid right now but I have to ask what you mean by
"define the property sheets as part of your class"? Do you mean using
something like this in the DataSkin subclass:

def __init__(self,id):
    ps = self.propertysheets
    ps.get('CompanyData')._properties = (
        {'id':'name', 'type':'string',  'mode':'w'},
> up a single trigger that checks whether any of the attributes you want to
> mirror have changed, and then fires that off to the SQL db.  It would

By 'trigger' you are referring to a RuleAgent plugin? Hmm... I had briefly
thought about this, but most of the discussions relating to interfacing to
an external RDB seemed to indicate subclassing a SheetProvider was the best
course of action. I'll have look into this (hadn't spent much time figuring
out RuleAgents yet).

> actually be a bit easier to set up if you were using a ZClass, since you
> could create the property sheets there by just adding "DataSkin Property
> Sheet" objects to the ZClass.  But the basic principle would still apply.

We've come to the conclusion that ZClasses really are more a hinderance
than a help, trading functionality for shorter learning curve. With
straight python code you get much more control and the ability to use
conventional editors and tools (cvs), without losing anything besides a bit
of time figuring things out (which is better in the long run anyways).


John Eikenberry
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to