CCK

Hi All

I am slightly following the CCK possibilities for about a year already and I think I am able to try it eventually live as it seems to be a good solution to a number of my problems. Unfortunately I am not sure where to get started. I've got plenty of traditional blog posts on my site and I am not sure how to convert them to CCK nodes or whether there is such possibility at all.

Could you, please, tell whether it is possible not to start CCKeing from scratch, but to convert existing content into CCK nodes? Any pointers to tutorials would be highly appreciated.

Problem

There are many modules that provide half solutions to the problem of referencing nodes in a hierarchical nature. We spoke with webchick about this tonight as a matter of fact. The probnlem rather simply is that while you can use nodereference field to relate nodes (and types) hierarchically ("My car" references "CVR" which references "Honda") this prevents you form storing that information with the actual node for use in views (sorting, filtering, etc) because only 1 portion (the first parent) of the relationship is stored at any level.

Possible Solutions

So I have a CCK form for a "problem submission" form. The authenticated user pulls up the form, fills out the fields displayed (field permissions hides fields that the office fills out) and hits submit. Then the office can go in and make changes, add information and update the "progress" (workflow) of the problem. Anytime the status changes ('submitted', in progress', 'oh hold', 'completed' etc.) I have the Actions module send an email to the author. Everything is working fine, but I would like to extend it in one way, and this is what I need help with:

Hi folks.

I'm about to create a simple module – I've named it nodegift. It allows admin to choose any content type and use all nodes of chosen content type as a “gift”. See mockup.

KarenS has kicked off a discussion on CCK field structure for core in D7. It's also webchick's itch of the week.

David Strauss is already commenting, and has experience in RDF from the Internet Archive, but it would be good to have other experienced people giving this the once over. Since these fields are likely to be a major way that people "transparently" create subject/predicate/object relationships, we better get this right (and performant, working on shared hosts, etc. etc.).

Here are my notes from the Future of Fields presentation from this morning.

[Begins showing a picture of the Data Architecture design Sprint including: chx, yched, bjaspan, crell, karens and nedjo]

Drupalcon used to be a developer conference where they would meet and figure out what was going to happen for the next year, but in Barcelona they realized that it was harder to do that.

So they asked about the who are the right people to be involved, and they all flew into Chicago and did a sprint.

Tradução do módulo CCK (Content Construction Kit), seria interessante uma revisão antes de enviá-lo para o mantenedor do projeto.

I'd like to get field permissions into CCK core in the D6 version. It won't be right away, it will be a phase II activity once the initial release is out the door.

One question is what a simple UI would look like, adding checkboxes for each field to the user permissions page is unwieldy.

I'm opening this page to stimulate some discussion, and hopefully ideas, on how to do this.

Some of the issues to be addressed:

• What will the UI look like if we don't add checkboxes to the user permissions page for each field?

I have been playing with the CCK head and my modal dialogs, and you can see the result at:

http://www.citris-uc.org/blog/tao/drupal_modal_dialogs_and_cck (2 minute loop)

I am particularly happy with the new ability to detect if the drag-and-drop table has been modified, and to offer to save the current progress.

Aside: Those of you paying close attention might have noticed me cheating. The /admin/content/types page doesn't actually have "fields" links. But it should (http://drupal.org/node/215623)

As we get nearer to our fine meeting, I am getting more worried about scope. Specifically, I fear we will bite off too much and accomplish little of substance.

I strongly propose that we focus on "fields in core" as a primary task. It is true that this goal splinters into many subtasks. But we should only concentrate on those subtasks which are prerequisite for achieving the goal. I think we can ignore node render and web services and PDO and lots of other shiny apples in favor of this one. It is the feature most requested by our user community, IMO.