Re: Schema provider/CA lookup status

Martin Aspeli wrote:
>
>
> 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.
not sure I follow you here.  ISchema(instance) only returns the schema 
in-toto for that instance.  It would encapsulate anything else(just like 
Schema()).  There is no requirement for ClassGen to exist inside or 
outside of an adapter in your example...putting it inside make it 
possible for someone to change the implementation to fit their needs 
without using inheritance(thus avoiding migrations and other headaches).
> 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)
>
I think currently I would opt to encapsulate everything within Schema() 
in an adapter.  Then one could choose the default behavior, or extend it 
at will.

but we are close...


@zope.interface.implementer
@zope.component.adapter
def schema_fetcher(context):
   schema = context.schema
   generateSchemaAccessorAndMutatorMethodsIfNecessary(self, schema)
   # and do any other extension you want
   return ImplicitAcquisitionWrapper(schema)
    
def Schema(self):
    return ISchema(self)

> 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.
>
which I think is fine...I just think that ISchema is the encapsulating 
entity here.  I want elaborate extension via ISchemaExtender, then I 
register an adapter to handle that, if I want the default, then I leave 
the registrations as is.  the really cool about what you've done is that 
if you encapsulate it as an adapter, you can easily switch in your 
behavior for the default or vice versa.

> Of course, if the ISchema adapter logic existed, 'company' would 
> simply have its own ISchema adapter and then implement that using the 
> extender magic.
>
bingo.
> 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.
I'd say we would be exactly on the same page and we'd be able to give 
people an option for dealing with their schema. 

Your extension adapter could be a nice way to solve alot of those "I 
need one extra field" problems without subclassing and proliferation of 
unnecessary type info.

-w

>


-- 
 
 | david "whit" morriss 
 |
 | contact :: http://public.xdi.org/=whit 

 "If you don't know where you are,  
  you don't know anything at all"        
                                     
  Dr. Edgar Spencer, Ph.D., 1995     


 "I like to write code like  
 other ppl like to tune their 
 cars or 10kW hifi equipment..."
 
 Christian Heimes, 2004



-------------------------------------------------------------------------
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