[Zope-CMF] Re: Re: Re: [Plone-developers] Re: Re: The components of
Archetypes
Martin Aspeli
optilude at gmx.net
Sat Jan 14 19:53:31 EST 2006
On Sun, 15 Jan 2006 00:32:53 -0000, Sidnei da Silva
<sidnei at enfoldsystems.com> wrote:
> On Sun, Jan 15, 2006 at 12:06:43AM -0000, Martin Aspeli wrote:
> | So - one problem is that there is a lot of Plone software out there
> that
> | just assumes all content types are Archetypes.
>
> If you know about software that does this, please speak up. Best I can
> tell there's no software that depends on content type being
> Archetypes, though some stuff like the ReferenceBrowser depends on the
> IReferenceable API.
To be honest, I can't really think of any specifics right now, but a lot
of things in the collective or plone.org/products that intends to be
generic say "for any Archetypes type", for instance.
> | But beyond that, CMF requires a lot of boilerplate, like above, that
> I'd
> | rather not have to remember or deal with. So, what are the options?
>
> Does it? I think CMF basically needs a portal_type (I think the class
> that provides this is DynamicType or something). Other than that the
> *content type* doesn't need much boilerplate. What you need is to
> register the factory type on the portal_types tool, but that's not
> part of the *content type*.
Technically, yes. But for most people's real I-need-a-content-type use
cases, it also needs the factory (so what if it's not technically part of
the content type? I still have to write the fscker), and it needs DC
meatadata and catalog awareness and a small raft of other things we take
for granted. The framework we promote needs to make these things easy for
the end user. Every line of boilerplate I have to write is a line that's
hard to explain to a beginner and becomes unnecessary maintenance burden
when either you screw it up or the underlying framework changes its
assumptions.
Martin
--
(muted)
More information about the Zope-CMF
mailing list