Our story for re-using content types

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