Re: Our story for re-using content types

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.


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.


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.


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.


-w

Martin Aspeli wrote:
> Hi guys,
> 
> This has been bugging me for a while, so I thought I'd take it up
> face-to-face. Re-using content types that are part of more complex
> relationships can be fairly difficult. I'd like to discuss what options we
> have, and how to approach this in the future.
> 
> Let's say I have a content type Staff that holds some basic contact details,
> and another type Project. Staff can be a member of the project, and this is
> modelled with a reference from Project -> Staff called projectMember.
> 
> I may build some clever functionality into Staff and Project, but any
> organisation wishing to use this product will probably want to manage their
> own metadata and view templates for staff information and project
> information. The problem is - how do they re-use this?
> 
> 1. Make a parallel class hierarchy: Derive MyStaff from Staff and MyProject
> from Project, and manipulate the schemata accordingly. This will probably
> involve duplication of most of the boilerplate FTI stuff and probably also
> duplication of templates etc. unless the original templates had well-defined
> slots for custom metadata to override.
> 
> 2. Monkey patch Staff and Project with custom metadata, and provide skin
> customisations
> 
> 3. Use ATSchemaEditorNG to make some fields editable site-wide or container
> managed. ATSENG scares me, though :)
> 
> 4. Externalise some of the customisable metadata to a tool similar to how
> portal_metadata is supposed to work nowm and deal with it generically in the
> edit schema (similar to how the portal_metadata facade works) and view
> template.
> 
> 5. If we weren't using relationships, but containment to model the
> relationship between staff and project, perhaps more likely in a Department
> -> Staff relationship, then a custom product could derive a type from Staff,
> and then modify the allowable content types in the FTI for Department upon
> installation.
> 
> I don't really like any of these options, though 1 seems to be the safest, 2
> the most convenient and dangerous, 3 the most flexible at a possible cost of
> performance and migration woes, 4 will likely to difficult to implement, and
> 5 useful only in simple cases. There could be additional complications as
> well, if for example the Staff type was referred to by hard-coded name in
> any catalog queries etc. driving the Project type.
> 
> In the future, I expect we may make better use of adapters and zope 3
> interfaces for this. I'm not sure how you'd deal with the reference
> allowed-types list without some changes to AT (as far as I know, this can't
> be made run-time dynamic?) but the allowable types may be looked up using
> adapters/utilities and ConstrainTypesMixin, and if anything that depends on
> content type functionality is written to an appropriate interface with an
> adapter lookup (that may just be the AT content type adapting itself to that
> interface), then there is some hope to re-use elements of the functionality.
> Similarly, if templates are written with appropriate slots, they may be
> easier to re-use.
> 
> I'm wondering what people have done in the past, and what they've found to
> work best. Indirectly, I'm also looking for how we can improve AT itself,
> and not at least our documented (?) "best practices" to make this easier in
> the future.
> 
> Martin
> --
> View this message in context: http://www.nabble.com/Our-story-for-re-using-content-types-t1386643.html#a3724583
> Sent from the Archetypes - devel forum at Nabble.com.
> 
> 
> 
> -------------------------------------------------------
> 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



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