[development] CVS HEAD, code freeze, zeitgeist
ber at webschuur.com
Fri Aug 18 18:58:01 UTC 2006
Op vrijdag 18 augustus 2006 16:42, schreef Mark Fredrickson:
> 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
Besides this, there are some fundamental design flaws in CCK. And no, my
resources are spread too thin, to fix this. Partly because I am still trying
to get flexinode stable, partly because I simply don't understand some
choices and parts of the CCK code (That after working 5 months full time on a
One of my current projects is what I called flexinode2. (though I was told I
should not use that name). One of the pleasant surprises is that core
node-type-builder allows me to get this off the ground a lot faster, since
that is a big part of what I needed, /and/ done right.
http://webschuur.com/node/643 is a quickly hacked up ERD, for this.
But in very short: use formapi/nodeapi to inject fields into node types. Split
out MV and C. (M=Field types, V=theme and NOT code in a field, presentation
and data should not live in the objects/enties, C = Field instances)
esp the V part is what bothers me in the design of CCK. But the concept of
fields/widgets combined with mutiple etc instances makes it far more complex
then it should (IMO) be.
Compare a flexinode image field (50 lines) and a cck image field (500+ lines),
to see what I mean. Not that I mean that flexinode has a better architecture,
just that it is better from a very pragmatic pov, because simpler.
I am looking for that simplicity, with the normalised architecture of CCK.
which i'd love to make flexinode2.
More information about the development