[TransWarp] Re: DataSkins and Zope3

[Phillip J. Eby]

At 01:29 PM 12/14/01 -0500, Steve Spicklemire wrote:
>Hi Phillip!
>
>I'm glad to hear your voice in this duscussion! I'm very interested in 
>seeing LoginManager, or at least LoginManager features avaiable in Z3, if 
>not "built in" at least "possible". In an earlier thread you mentioned 
>that the new Z3 component architecture would remove the need for ZPatterns 
>altogether. I've snooped around the Tutorial, and the Wiki, but I'm having 
>trouble seeing how you'd be able to do something like DataSkins in Z3 
>without ZPatterns. Would you mind elaborating just a bit on your line of 
>thinking here? Is this where TransWarp could allow you to "weave" whatever 
>storage option you like? Will it be as flexible as SkinScript attribute 
>providers and agents?

The short answer is "yes", to the last two questions.  More detailed 
discussion is probably best done on the TransWarp mailing list, as it's of 
limited relevance to Zope 3 development.

I will mention, however, that since Zope 3 allows you to wrap more or less 
arbitrary objects with viewers, editors, etc., it's not necessary to kludge 
attributes directly in order to support swappable storage 
mechanisms.  Instead, one can simply use get and set methods (ala JavaBean 
properties) on the problem-domain object, which delegate to some type of 
"data object" which manages storage for the object.

Notice, by the way, that you don't even need TransWarp in order to 
accomplish this - you can just write something yourself.  But TW will 
include libraries for dealing with this in three layers: domain, dispatch 
(think of it as being like the SkinScript/providers layer), and data 
(similar to Shane's DBAPI, but with caching and other goodies).  The domain 
support and part of the dispatch support is in CVS now, and I hope to begin 
check-ins of some of the data layer support over the weekend.  With any 
luck, by year end I'll have some test programs using all three layers to 
implement some simple LDAP-SQL integration tasks.

There are several questions in my mind right now about Z3-TW 
integration.  Mostly, they deal with fine details like how acquisition will 
actually work, security assertions as they relate to attributes vs. methods 
in interfaces, but they also deal with terminology and concepts.  TW is 
built around the assumption that the "static" portions of an application 
are represented as Python code, while some of the Z3 stuff "smells" like 
there might be ZODB-specific assumptions lurking somewhere just out of 
sight.  That's why I'm watching closely for those kinds of things and 
throwing an exception when I spot them.  :)