[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