Re: Schema-by-interface options

On Wed, 20 Sep 2006 15:46:40 -0700, Martin Aspeli <[email protected]> wrote:

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

the primary purpose is providing per instance customization, but the  
global, flavor on by default is possible, via few means, one is a custom  
flavorprovider adapter that always returns the global flavors (with  
adapter specification for either ITaggable or IBaseContent), but doing so  
requires forgoing marker interface application to content which are  
applied & removed during flavor lifecycle/mutation management, and which  
are central feature point of the system, ie. being able to apply both AT  
schemas, and z3 components at runtime on an instance basis.

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

per instance, adding an additional per class semantic seems strange in my  
opinion, in that AT already provides this. i could add an additional  
semantic for global application of flavors,  although i'm still unclear on  
the use cases, though its easy enough for integrators to add global  
semantics with per site customization via an objectcreated event adapter  
for flavor application in zope 2.10.

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

flavors are mostly just sugar around adapters, a local component registry,  
and changing all the adaptation lookups to provide context ( assuming some  
appropriate icomponentlookup adapters for AT content) would allow for  
this. however the system is currently targeting z2.9 and plone 2.5,  
because we need it production now for a high traffic site, and considering  
the new component registry machinery in zope 3.3, its not worthwhile to  
investigate/implement till the system is ported to zope 2.10.

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

the class cache is a broken semantic, if you want to be being able to  
apply by instance. once you have per instance semantics, caches become  
tricky, due to the need for at initialization of accessors/mutators per  
instance, and you have the notion of ordered schemas which allow for field  
overriding, or class directly implementing custom accessors/mutators for  
applied schemas. that said there are some potential optimizations here for  
a smart cache, with a lookup of (class, flavor name tuple) -> (schema,  
accessor/mutator dict) for limiting memory consumption and composition.

>
>   - Why is the FlavorUtility not registered as a utility?

because it was a decoy, its been removed, this code has been under active  
development all day ;-) its stable after as of this email, in that feature  
development is complete.

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

the at minimal mixin the system needs is in aware.py..  basically just  
delegates for Schema() and getIcon(), the schema delegation could be any  
such implementation that defers to the CA for an adapter, and  
contentflavors could integrate for management, though i have questions  
regarding getting the z3 management ui view on applicable adapatable  
content, without a declared interface on the content.

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

yes, this is possible, minus the icon use cases which i'm happy to forgo  
for more generic integration scenarios, as making this functionality  
useful in plone 2.5 requires custom navtree/folder content components and  
are project specific anyways. when the type specific css icons go away in  
plone 3.0, it might be worth consideration again for generic integration.

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

such functionality is already duplicated elsewhere (atseng comes to mind)  
to support different semantics, one implementation to rule them all doesn'  
really seem all that z3ish ;-)

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

i hated the name before i started.. but went with it to minimize  
introducing new client vocabulary, as alternatives we considered Facets  
and Behaviors, facets sounded better, behaviors denote some more AOP style  
semantics then i think are actually given. but i'm out of time to do name  
refactoring, though patches would be welcome.

cheers,

kapil

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