Options for making AT schemas more adaptive

Hi guys,

Whit made a very important observation the "story for re-using content  
types" thread that (a) logic should be in adapters outside the content  
type and (b) without that, the content type is just the setup code, the  
CMF boilerplate and a schema. You probably don't mind creating a new FTI  
and deriving from BaseObject and doing the installTypes() in Install.py if  
you're trying to re-use a content type and you still want a *new* content  
type. It's trickier, however, having to duplicate or override the schema,  
especially if that schema is involved. And, if all you wanted was to  
change some behaviour in that schema, creating a whole new content type is  
a pain.

Whit noted:

"""
I would say the major step to make here is making BaseObject.Schema use  
interfaces to return the schema.
second step is to remove the schema as a tree of persistent object inside  
the content (unless instance local
configuration of your schema is part of your usecase). where it come from,  
the interface doesn't care.
"""

I'll extrapolate two real use cases from that:

  - I want to write an adapter that provides a somewhat different schema  
(or part of a schema) for an existing content object without registering a  
brand new content object.

  - I want to inject something into every schema, for example some  
site-wide required metadata. Take for example PloneOntology, which  
requires you to choose some keywords when you save a content object.  
Currently, that either requires a separate object tab, which sucks because  
people don't necessarily click on it, or a monkey-patch to BaseSchema  
(ouch), or a custom field/partial schema that every content type needs to  
explicitly include.

Both of these directly relate to things I really want to enable with Plone  
3.0: (1) generic UI mechanisms for things like PloneOntology or a tagging  
system or anything else that needs to apply site-wide or generic metadata  
and (2) improved re-use of existing content types (my main gripe is all  
the people who want PoiIssues to have a RichWidget instead of a TextWidget  
with intelligenttext).

I'd like to discuss some general design ideas for how we can achieve this  
without having to re-write all of Archetypes, but obviously in keeping  
with the evoluationary path of making AT more re-usable and less  
monolithic.

Two potential caveats:

  - there may be several components installed that want to, say, inject  
metadata into every schema for different purposes (e.g. you have a  
company-specific metadata provider + a tagging solution installed)

  - only when a product is actually installed should these things apply

I'm going to think about this in more detail too, of course, but some  
specific design outlines would go a long way towards letting me write a  
PLIP for this.

Thanks,
Martin

-- 
(muted)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642