Phillip J. Eby wrote:
If I can offer a suggestion...
Please...
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): self.DataSkin.__init__(self,id) ps = self.propertysheets ps.manage_addPropertySheet('CompanyData','CompanyData') 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 [jae@zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin