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 CCK project!). 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. Bèr