Re: Schema-by-interface options

Kapil Thangavelu wrote:
> i had a need for this and a bit more functionality for a client today 
> and whipped up a ContentFlavors product. whats it do .. readme excerpt..
> 
> What are flavors?
> -----------------
> 
>  are bits of behavior and schema that we can add to content at runtime.
>  we can gain additional access to icons, actions, views, adapters,
>  and at schemas via adding a flavor to a piece of content.
> 
>  A flavor is composed of a number of optional parts, typically an
>  archetypes schemas to compose, marker interfaces to apply, some ui
>  metadata and an icon. see the readme, zcml section, for complete 
> definition.

This is quite interesting - need to look into it a bit more, but sounds 
like a good match for what we're trying to do here. Having a more 
fully-featured solution that can be an optional dependency for things 
that need it is quite attractive.

A couple of random concerns/questions:

  - Does this have any mechanism for adding things to schemas more 
globally, i.e. install a 'tag' field on all ITaggable or an 
'annoyingCorporateContentIdNumber' on all AT objects?

  - Do you support extended schemas per-class or per-instance?

  - Is it possible for a particular flavor to be installed in one Plone 
site but not in another (in the same Zope instance)

  - Do you cache schemas in a _v_ attribute only? This may have a 
performance impact; the approach on my branch and in b-org uses a cache 
(keyed by __class__) that needs to be explicitly invalidated (via an 
event). Maybe I'm missing something though.

  - Why is the FlavorUtility not registered as a utility?

  - What is the minimal extension to AT you could imagine that would 
allow Flavors to work without requiring a mix-in (thus being general and 
backwards applicable), but without making AT depend on ContentFlavors?

    For example, I could imagine that we could go back to Whit's 
original schema-by-iface implementation which only adapts self to 
ISchema (I have some issues with his implementation, though I think it 
can be made nicer with a custom adapter factory method), and then let 
ContentFlavors handle the actual use cases for extension.

   The main problem is that, as you've discovered, you need to 
re-generate methods ClassGen style when things change (and at least 
once) at run-time, since ClassGen is only run once and is only aware of 
the 'schema' class-attribute. This has performance implications, if 
nothing else. I'd rather that functionality was in AT.

   You probably have a better idea than me about exactly how that'd 
work, though.

  - s/Flavors/Flavours/g (may not win that one...)

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