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
_______________________________________________
Archetypes-devel mailing list
Archetypes-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/archet
ypes-devel
|