[ZPatterns] FreeRangeDS almost but not quite... any thoughts?

[Steve Spicklemire]

Hi ZPatterns Folks,

I was hoping for a quick hack to use ZPatterns in CMF. I cooked up 
"FreeRangeDS" as a sub class of DataSkin that looked for its data manger 
at wrapping time (overriding __of__), and found one by calling an 
acquired method "getDataMangerFor". I can put a "getDataManagerFor" 
script anywhere (e.g., CMF root) and instances FreeRangeDS would find 
it, and call it, as they are being acquisition wrapped. I tested it a 
bit, and it seemed to work, more or less. Yeah. ;-) Now I'm really 
trying to *use* it and I have some weird behavior. I've created a 
subclass of CMF Document. When I first create a new instance, it finds 
its data manager, and when asked for things like "description" and 
"subject" it correctly looks up the right SkinScript and the attributes 
are provided correctly. After I "edit" the Document (I don't have any 
setters defined yet), the attribute providers are never called again. 
Shouldn't attribute providers have priority over persistent attributes? 
Do I have to define setters as well as getters?  I added a print 
statement...

     # Attribute handling

     def __get_attr__(self,name,_v_dm_=_v_dm_):

         cache = self._v_attrCache
         v = cache.get(name,_marker)

         print "checking for attribute: ", name, " using dm-> ", 
`_v_dm_` , " got ", `v`

         if v is _marker:
             v = 
getattr(self.__class__,'class_default_for_'+name,NOT_FOUND)
             cache[name] = v

		blah blah blah...


to __get_attr__ and found that indeed, the DataSkin __get_attr__ is 
never called after the object is edited. I guess I thought that 
DynPersist plugged in at a low enough level that this would never happen.

thanks for any insight ;-)

-steve