Re: Schema provider/CA lookup status

Martin Aspeli wrote:
> 
> whit morriss-2 wrote:
>> cool...will we still be able to register a schema by interface? wouldn't 
>> the classgen stuff go inside the adapter function/class?
>>
>> so if you didn't need the slight overhead, you could avoid it? or will 
>> all schema require this?
>>
>> I need to look at the code but anything you could do in Schema() should 
>> be able to be done in an adapter.  hopefully Schema() will go away 
>> eventually...
>>
> 
> I don't quite see the win in this. Schema() (well, the aq-wrapping is a bit
> annoying) is the canonical way of getting the schema of an AT object, and is
> part of the IBaseObject contract.

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.

> AT as it is now won't work unless ClassGen has had a chance to generate
> methods for every field in the schema. I'm not sure how wide-spread this
> assumption is, but there are many things doing a getattr(context,
> field.accessor) for example - assuming those methods exist. Without it, the
> checks fo whether a field is writable fail, meaning that they don't show up
> in base_edit.
> 
> The need to re-run ClassGen's method generation is general and ought to be
> in the framework, not a requirement of each adapter. If you look at
> http://svn.plone.org/svn/collective/company/trunk/content/schema.py you'll
> see how I use a slightly different pattern, looking up an ISchemaExtender
> that's allowed to extend the schema.

> Getting rid of the ClassGen assumption entirely is likely to be fairly
> invasive, since it's such a fundamental part of the interface to AT objects.
> OTOH, the pattern in the file above is fairly non-invasive and seems to work
> well.

that's pretty cool.

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

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.

-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