Re: Our story for re-using content types

On Thu, 06 Apr 2006 23:09:04 +0100, whit  
<whit-UE+B0n23d/[email protected]> wrote:

> I think content-type reuse is sort of a red herring, a dodo, an  
> epiphenomenal concern caused by issues with the existing system.  what  
> we should be worried about is code reuse.  content-types are a  
> usability, information architecture concern that has become lodged in an  
> non-malleable state at the implementation level far below it's  
> operational level.

A good observation. Here's a driving factor: Every man and his dog has a  
different idea of how Poi issues should work and what fields it should  
contain. As it stands, they have to monkey patch or re-invent a lot of Poi  
just to, say, make the main issue edit field use kupu or add a couple of  
fields to the schema. That sucks. :)

In part, this could be fixed by coding defensively. All the functionality  
(there's not so much really, but there's a bit) should become view classes  
+ other adapters. Wherever the names like 'PoiIssue' are hardcoded, they  
should be generalised away behind some interface (perhaps using a marker  
interface).

So that's more about patterns than actual technology. But we need to get  
those out there. Short of maybe listen and perhaps Membrane, I'm not aware  
of any content-centric code that actually uses these patterns. There's  
certainly no documentation that preaches this story (I hope to fix that)

> currently the lynchpin is the schema.  almost everything else short of  
> the basic streamlining of CMF type setup and references can be done with  
> adapters. In other words, the only reason to create a content type other  
> than folder or basecontent is for a schema and an FTI.

Yes. I've come to think of the CMF boilerplate (PortalType, basically,  
+ an FTI and the relevant bits in Install.py) as the same as the  
Persistent base class you use in pure Zope 3. If this is just the storage  
layer, than that part itself is swappable - especially if you define an  
interface for the parts of its schema that are meant to be referenced by  
other code. If all the rest of the logic and behaviour are adapterised and  
interfaced away, then you can still have a reasonably clean design.

> I would say the major step to make here is making BaseObject.Schema use  
> interfaces to return the schema.

I've been thinking about this. One simple way would be to just have an  
ISchemaProvider that can return a Schema based on the context. I'm sure  
there are finer grained ways of doing it, though. I know Rob was thinking  
about it too. Ideas?

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

Yes.

It'd be really useful to gain some understanding of exactly how much work  
this may be.

> following this general meme, tiks (http://tiks.org/) uses a model where  
> no behavior is part of the content object at all.  all behavior comes  
> from adaptation and event and all data is stored as annotations.  the  
> designers of tiks did it this way specifically in reaction to the  
> headache of content-type reuse, migration, etc in CMF/Plone.

I think that's the same thing I've come to. Not sure if everyhing has to  
be annotations as opposed to "real content", except perhaps for the fact  
that you can then work through an IAnnotatable? My perception of  
annotations was that it was for "additional" metadata, not the main data  
stored in the object itself.

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