I was VERY skeptical about the CCK-driven future. I had a chat with JonBob about his 'vision' for the new system, and if I understand it correctly, he's working towards something like this: CCK 'field types' are specific kinds of data, like URLs or images or large blocks of text or numbers or dates. CCK 'widgets' are UI elements that edit those pieces of data (like a dropdown list of user accounts) CCK 'content types' are defined collections of fields, with the settings regarding which widgets should be used to edit them. (One field type may support numerous different editing widgets for different UI needs) Aggressive use of caching would reduce the performance hit for loading content types defined in this way, just as caching today speeds up the loading of node types that have many corollary tables added via nodeapi. A module that defines a new content-type would just expose a blurb of metadata that describes the content type in terms of fields, widgets, etc. If it needed special kinds of fields or widgets, it would implement those as needed. This would be a lot like views.module, and how it handles custom data, custom field definitions, etc. Modules would still be able to expose custom handling code to impose additional validation rules, post-processing, etc. But a world of additional possibilities would open up; users who need a custom field or two would be able to simple *add* those fields to 'blog' or 'page' using the CCK infrastructure. No custom code needed. I'm probably not explaining it very well, but after my conversation with him, I was convinced. I think it has a LOT of potential. --Jeff -----Original Message----- From: Khalid B [mailto:kb@2bits.com] Sent: Sunday, May 07, 2006 5:43 PM To: development@drupal.org Subject: Re: [development] hook_foo() vs. nodeapi On 5/7/06, Larry Garfield <larry@garfieldtech.com> wrote:
This seems to echo the "why make nodes when you've got flexinode" idea
that was floated a while back. The answer then and now being "because
sometimes I don't want my data's definition and structure in the database, I want it in code where I don't have to do everything twice between a beta site and live site."
Here is an idea: I would call "portable node definitions". This can be some sort of predefined node data that would make a fresh site have the new node types. These can be some sort of metadata file, and can be as simple as some PHP code that does that, or can be Yet Another Metadata Proposed Format. This way, instead of having a classified or job search module, we would have a metafile for each, and that is it.