Content Construction Kit (CCK)

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
2. Build-in categorization features.
3. Build-in views features (listing fields, not necessary nodes).
4. Build-in menu features.
5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

Webchick has been helping me launch a new top-level CCK handbook at http://drupal.org/node/101723. So far all that has been done is to re-organize existing pages, but I'm going to try to gradually get more information added (and update or weed out outdated or inaccurate info). Anyway, if anyone has anything to contribute, suggestions, ideas, etc. etc. please jump in and add pages or comments or whatever to the handbook. Even if you don't know enough to create a page, if you think of a topic that needs to be addressed just create a stub page that someone else can build on.

For starters, I set up 'CCK for Administrators', 'CCK for Developers', 'Installing and Updating CCK', 'Related Modules', and 'FAQs'. The last one is an old page that was already there and may not really make any sense any more since the whole thing is sort of a FAQ, but I left it for now.

I've been thinking about some of the specifics of creating a personal workspace within Drupal -- although my main area of interest is education, these thoughts have applications outside education -- these are some rough notes, and I'm curious to see/hear reactions about what I'm missing/overlooking. These notes are not intended to be comprehensive, but a starting point in a conversation about some specific functionality

Some basic functionality--

<

ol>

To accomplish this, I was thinking about some integration between BuddyList (http://drupal.org/project/buddylist) and the ACL (http://drupal.org/project/acl) or NodeAccess (http://drupal.org/project/nodeaccess)module -- members of a user’s Buddylist can be used to form an access control list on a node by node basis-- I’m leaning toward the ACL module as I think a generalized API that can be used by other modules provides some advantages long term. However, was the ACL module designed to work primarily with roles, or with individual users?

I created a new node type (the old-fashioned way). Now I'm playing with CCK, seeing what it takes to re-create this node.

Now, say that I have a piece of custom code, and I want it to run in one of the hooks/handlers, eg. an extra bit of validation, or some form_alter on the node_form. What would be considered "best practice" to implement this piece of code? In reality, do I need to hard-code this logic into a simple node module, and then use CCK to extend the fields as I require?

I imagined another tab in the CCK creation, where I could select a handler, and then submit php code that would be executed at that point. I had a little look in the issues queue regarding this, I don't think there was anything there, or maybe my search terms are wrong...

I have a mostly-working Views Calendar module available at http://www.drupal.org/project/calendar. It's still a little buggy and the css needs tweaking but it is generally working. Create a view and select the Calendar display (instead of table or teaser). Add any date field to the view (CCK dates, event dates, node updated dates, whatever). Add three arguments, Calendar: Year, Calendar: Month, and Calendar: Day.

Navigate to the view where you will see a year of mini calendars. Click on a month name to see the month or a day name to see the day. Back and next navigation is provided for month and day views (not yet added to the year view). It comes with a default calendar that displays all nodes in a calendar by their last updated dates. If you like, select the Calendar view for the block, too to get a mini calendar in a block.

The good news is that we have an initial version of CCK for Drupal 5.0. The patch to make this happen was the work of several people, dopry, drewish, yched, edrex, maybe others. Drupal 5.0 introduces several changes, most notably moving the handling of content types into core.

I wanted to start a place here where we can discuss development of CCK 5.0 to take advantage of new Drupal 5.0 functionality.

Here are some of the changes/opportunities/challenges I see so far:

1) You can now add CCK fields to any content type (at least any content type you create and manage using the core content types administration screen). I predict there will be a big wave of interest in CCK when people see they can do that (and a lot of new people who may need support).

CCK is making great strides towards enabling application design within Drupal. One feature that seems essential is the (optional) ability to enforce referential integrity for nodereference and userreference.

Taking up Robert's example: another real knockout criterium that prevents this from working is that there is no way to ensure that once we record that Beethoven! wrote the moonlight sonata that it stays that way. At the present, is seems that Beethoven could get deleted and leave the sonata orphaned?

If a content node A refers to node B (or user B) then Drupal could guarantee that node A does not get orphaned.

What?

A few days ago, I compiled a list of all the node review modules I could find at the time, and wrote up an article comparing them: http://www.lullabot.com/articles/a_review_of_node_review_modules. The amount of overlap in these modules is, quite frankly, stunning. Yet they all do slightly different things. Node Review handles multiple axes. Simple Vote merely stores the aggregate score for a node. User Review allows you to place a comment with your vote. Vote Up/Down handles a simple "yes/no" style of voting.

It occurred to me that if we took a step back, we might be able to develop "one voting module to rule them all." Rather than having to keep implementing these new voting modules because others "almost" do what we want but not quite.

I've looked briefly at customvote.module, which looks as though it endeavors to be that tool. But I'm thinking something slightly different: a voting API field for CCK.

Drupal core has had configurable content types for awhile now. What is the plan for removing those from CCK and having the field system added via nodeapi or formapi? This really should work well on the next release of Drupal and would provide something better to look at and evaluate for moving fields towards core.