[development] CVS HEAD, code freeze, zeitgeist

[Bèr Kessels]

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