CCK integration with nodeapi

I have begun to do just that.
I agree it would be nice to have this. Any field could be added to any node (CCK or external node type). Among the benefits, CCK could become a general solution to doing node-to-node and node-to-user associations, for any Drupal node type.

I have basically forked content.module and content_admin.module, and made these changes:
Replace _content_types() with _addcck_types, which retruns all array of all NON-CCK node types
Replace all calls to _content_types to call _addcck_types() instead.
Caching added fields w/ "addcck:" identifier
Added addcck_nodeapi() which handles form, submit, validate, insert, update, view, load operations
Added addcck_form_alter which adds the desired widgets to the appropriate node forms

I have not fully hooked up all admin features, but currently you can add fields to non-CCK node types. The form fields seem to properly render, and the values show up in the node view page. The admin interface is added to the CCK admin interface, at administer->content->content types

Add 2 files to "addcck" folder, inside of "modules" directory. First file attached here, second attached in next post.

Please advise if this is in the right direction, issues, thoughts.

Here is the 2nd file.

I don't want to discourage discussion/development along these lines, but this won't go into the 4.7 release. I don't want to turn this module into an add-on for traditional node types unless/until it becomes clear that we cannot accomplish all of what traditional node types do with constructed types.

If you can abstract this work off into a separate module that uses CCK for its work, I'd recommend going that route.

certainly can abstract into a separate module (that requires CCK also be installed). In fact that is what is attached. Will consider publishing in CVS when everything is hooked up. Slightly concerned that given rapid dev on CCK my fork will get progressively out of date. But that's how it goes.

Sorry, by "fork" I assumed you meant "fork." :-)

JonBob,
I do think CCK has 2 aspects
(1) node types
(2) fields
In both respects it offers a robust solution. I think the fields can be productively decoupled from the node types. I already see people aspiring to add more fields to CCK. The CCK field hooks will likely be a favorite avenue for 3rd party modules to expose form widgets. E.g. see http://drupal.org/node/58655
The new module addcck would permit any such widget to be addable to any node type.

The process of "forking" CCK & enabling it to add fields to external node types was pretty smooth and seems to integrate nicely w/ your existing tables.
The main caveat was that I had to replicate a lot of code because of 1 line, which repeatedly hard codes the association between CCK fields and the CCK node types. That line of code is

$types = _content_types();

This line of code appears at the beginning of several functions, and in many cases it is the sole reason I must otherwise fork/replicate a CCK function in my module.

I propose that you could make a slight modification to some of these functions to enable my module to introduce its own array of content types, so my module needn't replicate a forked version of your code. So for example I propose you could change

function _addcck_widget_invoke($op, &$node) {
  ...
  $types = _content_types();

to this:

function _addcck_widget_invoke($op, &$node, $types) {
  ...
  if ($types == null) {
    $types = _content_types();
  }

That way I could pass in my $types array (containing all non-CCK node types). I could submit a patch that would do this simple change in a few functions. Of course, it should not change how CCK works. Then I would publish a slimmer "addcck" module which would leverage this. Shall I submit the patch?

Oops. change above post to

function _content_widget_invoke($op, &$node) {
  ...
  $types = _content_types();

to this:

function _content_widget_invoke($op, &$node, $types) {
  ...
  if ($types == null) {
    $types = _content_types();
  }

This is a patch.

OK, so CCK has changed since this thread began. Here is an update of the slight changes to CCK that would make the addcck module more stable & less in need of replicating significant code

these functions expect the content type to be a CCK content type:
_content_widget_invoke($op, &$node)
_content_field_invoke($op, &$node, $teaser = NULL, $page = NULL)

They both do this to determine the content type

_content_widget_invoke($op, &$node) {
$type_name = is_string($node) ? $node : (is_array($node) ? $node['type'] : 
$node->type);
  $type = content_types($type_name);

If they could permit the content type to be passed to them, then the addcck
module (or other 3rd party module) would not need to fork/mirror these 2 important functions. E.g. Change
the above CCK code in content.module to this

_content_widget_invoke($op, &$node, $type=null) {
$type_name = is_string($node) ? $node : (is_array($node) ? $node['type'] : 
$node->type);
if ($type==null) {
  $type = content_types($type_name);
}

These changes are not required but would be helpful.

The update to current cvs head, enables exactly this as node type creation is now handled by drupal core. see http://drupal.org/node/80335

I'm setting status to duplicate.... once the above mentioned patch hits we can probably update to fixed.