|
List Info Thread: Our story for re-using content types
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Our story for re-using content types |
|
List Info Thread: Our story for re-using content types
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
burningman.com> 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 (