Re: Options for making AT schemas more adaptive

On Fri, 2006-04-07 at 23:44 +0100, Martin Aspeli wrote:
> 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.

You said ATSENG scares you in the "re-using content types" thread and
I'd like to know why. Especially since it solves your Poi problems with
very little effort. We build most of our content types using ATSENG
these days and it really is such a painless way to add a lot more
flexibility to a product.

Maybe it's not the implementation that scares you but something else. If
it is, just see how easy it is to use ATSENG in a content type. First,
just override getSchema:

    def getSchema(self):
        # we are not wrapped yet
        if not getattr(self, 'aq_parent', None):
            return schema
        se = getToolByName(self, SCHEMA_EDITOR)
        return se.atse_getSchemaById('Person')


Register the schema with ATSENG in Install.py:

    SE = getToolByName(portal, SCHEMA_EDITOR)
    if not SE.atse_isSchemaRegistered('Person'):
        SE.atse_registerSchema('Person', person_schema, 
            filtered_schemas=('metadata', ))

Customising a schema in another product (This basically replaces a field
in an existing schema):

    person_schema = SE.atse_getSchemaById('Person')
    field = StringField('Username',
        atse_managed=ATSE_MANAGED_NONE,
        index='FieldIndex',
        widget=StringWidget(
            visible=True
            ),
        )
    person_schema.replaceField('Username', field)


I'm not saying don't use funky Z3 adapters to solve our problems in the
long run. I do however feel that ATSENG adds something to AT right now
that very few frameworks have: easy through the web customisation of
fields. Keep this in mind when move AT along to Zope 3.

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za



-------------------------------------------------------
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&kid0944&bid$1720&dat1642