[development] CVS HEAD, code freeze, zeitgeist

[Mark Fredrickson]

> Please elaborate.  What would you rewrite, and why?  What is not
> properly done in core that is a showstopper for full CCK support?

I don't intend to speak for Ber, but as someone who has spent many
hours trying to create an import/export/CRUD API for CCK types (not
nodes), I'll comment here.

The big problem that I see with CCK right now is that it ties a lot of
the logic into the form submission process. This is similar to the
problems we've seen with programmatically creating nodes. This is a
problem for the immediate need of allowing modules to define and
import their own content types (a la views). It is also a problem for
long term maintenence. There are at least three ways to create a
field, all of them tied to a different form. If the data storage
mechanism changes (again) that requires picking through three
different areas of the code, trying to synchronize the changes.

I think this also speaks to the issue of slowing pairing down CCK as
core. It's not easy to just drop out an API function and rely on core.

I think this speaks to a CCK rewrite (or at least a structured cut 'n'
paste). First build the API, then build the forms on top. As an
example, think views + viewsui.

-M