Re: Schema provider/CA lookup status

whit wrote:

> it's more of a general move away from class holding behavior to behavior 
> assigned by adaptation. As long as a particular behavior is marooned as 
> a class method, then you are stuck with the usual inheritance dilemmas.

That's very true. This probably falls within the AT-future vs. 
AT-oblivion debate, though. Let's have that another day.

> hypothetically you could start will generic content and work your way up 
> to whatever you needed. still sort of sucks for existing content.

That's precisely the thing 'company' is trying to demonstrate.

> Still I would argue that a mixin is completely unnecessary if Schema() 
> is deferring to a call to ISchema(then calling ISchemaExtender from 
> within the adapter).  Even if the adapter is still just grabbing 
> .schema, I think it gives you a bit more wiggle room and less 
> inheritance baggage.

Yes and no. It's certainly not necessary technically speaking. But any 
implementation of Schema() needs to do the ClassGen magic after it has 
found a suitable schema. Because that is always going to be the case 
until we fix AT to not require it (and at that point, should it come, it 
should go away everywhere at once), I think that putting it inside the 
default implementation of the IBaseObject -> ISchema adapter is a bad 
idea. It requires all other adapters to be aware of this implicit 
requirement and do it for themselves.

But we may be saying the same thing: AT's BaseObject.Schema() could do 
(pseudo-code):

def Schema(self):
     schema = ISchema(self)
     generateSchemaAccessorAndMutatorMethodsIfNecessary(self, schema)
     return ImplicitAcquisitionWrapper(schema)

My preference for ISchemaExtender is based on the fact that the generic 
content in 'company' depends on a few schema fields being there. The use 
of an "extender" implies (even if it doesn't totally enforce) this 
better than the use of a generic ISchema.

Of course, if the ISchema adapter logic existed, 'company' would simply 
have its own ISchema adapter and then implement that using the extender 
magic.

Are we on the same page then? I think if we took the ClassGen extensions 
from company's schema.py, and the Schema() extensions plus the cache and 
invalidation event, needed to keep performance sane from its mixin class 
but modified to use ISchema as the primary lookup mechanism, and brought 
all that into AT core (on your branch, but nouri said he was interested 
in merging it for 1.5) I think we'd be pretty close.

Martin


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV