Re: What does Five and Z3 mean for Archetypes?

Alec Mitchell wrote:
> 
> On Friday 18 November 2005 09:05 am, Sidnei da Silva wrote:
> 
>>On Fri, Nov 18, 2005 at 05:53:19PM +0100, Martijn Faassen wrote:
>>|
>>| Do annotations fit in somewhere? Zope 3 doesn't have a storage framework
>>| yet, so I think Zope 3 has some work to do here. ZPatterns gurus speak
>>| up.. :)
>>
>>One of the available storage components is a annotation storage.
> 
> AT's storage abstraction is nice in theory, but deeply flawed.  Because for 
> z3 schemas, the schema is the most abstract definition of the type, it makes 
> no sense to put storage implementation details at that level as it is in AT.  
> Doing storage at the field level has nice benefits for a few usecases 
> (storing specfic information about a user or customer object in LDAP for 
> instance), but is problematic for doing things like storing objects an 
> RDBMS, which is what most people seem to want it for (and they are often 
> disappointed as a result).  The storage picture needs to be worked out on a 
> level entirely apart from schemas and widgets, a baseclass that provides 
> some decorator methods/classes for storing and retrieving field values in 
> interesting ways would be essentially equivalent to the current AT storage 
> implementation.

ZPatterns introduced a way to map various object attributes to the 
actual provider of the attribute's data.  this data provider could be a 
particular ZODB-persistent attribute on the object, a particular ZSQL 
method, a particular python script or external method, etc.  whenever an 
object's attributes were retrieved, this layer would trigger the 
retrieval of all of the data, providing it to the object which would 
then use it as its attributes.

the mechanisms for gluing everything together would of course be 
different in our case, but i think ultimately this pattern makes sense. 
  some component would be responsible for mapping the fields to their 
data sources, and for retrieving that data when appropriate.  each 
particular data retrieval portion would only be executed once per 
transaction, so upstream code wouldn't have to worry about efficiency so 
much.

i haven't looked at how these ideas were developed in PEAK, we should 
definitely see if there's something we can make use of there.

-r



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click