Agent0x45

Unraveling some of the mysteries of the CCK api. Here are some of my notes.

I have descovered that one of the biggest problems with the cck api documentation is the lack of consistant terminology. For example, "field" can have 3 distinct meanings.

 

1. A "field type"
   
   • Each filed type has its own unique behavior
     • The node hooks are designed to work on a single field type. Most of them pass a reference to it in the $field variable
     • They are stored in the table {node_field} It has the following columns:
       • name and type (name is the long one used in forms)
       • global configuration (the most global level of configuration you can immagine a field having. not used an awfull lot)
       • a flag named "required" which means that fields of this type can never be left blank when a form is submitted (the cck does this validation, not the field implimentation, which can do additional validation)
       • a flag named "multiple" which is primarily used when selecting multiple items from a list.
     • The data that are stored, displayed, and made editable are defined by the field hooks for the field type.
   • In the context of a hook implimentation, this is usually just called a field.
2. A "field instance"
   • These are properties of individual node types.
   • They are stored in the table {node_field_instance}
   • I haven't yet found a php variable that stores a list of them. If there is a variable that stores the type, it will probably have such a list. Otherwise, I haven't found a variable storing these.
   • Each "field instance" is essentially  a field that has been added to a content type.
   • These are generally called  "field" when you are adding them to a content type
3. An "item" represents the data associated with each instance of a field instance
   •  It is often just a single value.
   • Each node has its own items.
   • If "multiple" is enabled for this node type, then there will be more than nodes can have several of these for each field instance.
   • I have seen these called field in several places in the cck docs, but not very consistantly. I mostly see "item" in the source.
   • Items are arrays that contain key-value pairs.
4. A "value" ... I haven't seen these called anything but "fields", and I am running out of names...
   1. I haven't seen any consistant termanology for these, but they are what each are stored in the php variables $node->field_... variables.
   2. They are arrays of items.
   3. If multiple is not turned on for the node type
      1. Then the only item will allways be in $node->field_...[0]
      2. and the items will be stored in the table {content_type_fieldname}
      3. The table stores
         
         1. the nid of the node the data is attached to
         2. A "vid" that is used to associate the item with a field instance
         3. the values defined by the field type (through its hooks)
         4. this table (as opposed to content_field_fieldname) guarantees uniqueness of (nid,vid) pairs
   4. If multiple is turned on
      1. The items are in an un-ordered list in $node->field_fieldname
      2. they are stored in the table {content_field_fieldname}
      3. The table stores the same info as {content_type_fieldname} would, except that (nid,vid) pairs are not unique.
   5. The names of the tables used to store records were different in Drupal 4 and earlier, but the contents are the same.

Also, I see the phrase "multiple fields" thrown around a lot. There is a lot of multiplicity in the cck. In many cases where a singleton is the most common case, arrays are used instead.

1. Each item can contain multiple values. These essentially represent columns in the virtual table for that node type. Items are arrays of key value pairs, with the key being the name of the column and the value being the data stored there. Most fields store, display, and allow the editing of a single value, and so the php variable $node->field_fieldname[0]['value'] often contains the value.
   1. Prior to drupal 5, the  nodes were stored differently. I see lots of code that uses $node->field_fieldname_value[0] instead of $node->field_fieldname[0]['value']
2. You can have multiple field instances of the same field type attached to a single node type, or to different node types.
   1. Each field instance has its own name, label, and some unique configuration
   2. The records are stored in the same tables. There isn't a table of items for each field instance, rather for each field type.
3. You can have multiple Items per field instance per node. That is what the multiple flag in the node_field table does. The affects are described above in "values

Also, there are 3 different circumstances when a field provides a list of its fields. It can return separate lists for each

1. The list of fields to save to the db, and the list of values to save to the db
2. When rendering the field
3. When editing the field (though this case is limited by the wigit used... the editing behavior is detached from the field)

This allows for very elaborite behavior. For example, a date can be presented as a single item when editing the node, can look however you want, but can be stored in an appropriate format (separate columns for day, week, and year, for example, to allow faster sorting and searching). Localization is often handled this way by cck modules.

 

 

That pretty much summs up the stuff that I found terribly unclear in the cck docs and source (including the sources of several cck modules). Its definitely not a complete guide (or even my complete notes) but if anyone else is struggling with the cck docs, it could save them a few hours of staring at phpmyadmin or the source of random contributed modules.  

 

 

So in a few short days, I will be empowering full time. I have been browsing over the empowerment, and looking at a lot of content that needs expanded and/or cleaned up. I have started filling in a few stubs that I created months ago, but much more needs done. If there is anything that you would like to see on the empowerment, but don't have time to add it, or content that exists but needs more work, post a comment here and I will see what I can do.  Anything that will take more than a couple of hours, or is way out side of my area of experties will get posted up to the mission system.

 

Also, add comments to any existing missions that you feel should be a higher priority or might need review, and post up missions for site improvements and feature requests (both for the iphone and regular www interface)

 

 

Other times I know I do.

 

It sucks working a soul sucking job because, not only does a sense of dread and disdain build up and grow, but also it drains the mind and body, leaving me exhausted and inept. I spend all day talking to people, explaining stupid shit, then when I actually have something worthwhile to explain, the words come out all wrong. My concentration fails me.

 

After finally finding the entry-level document to the Cocoa architectural guides (its titled "Cocoa fundamentals guide" and lays the groundwork for the other introductory guides) I read it for about an hour last night. It was fairly redundant after all the other reading I have been doing, but I still feel that its necessary, because any flaws in how I see the overall architecture now will be very troublesome later. When I started reading again today, about 20 hours after I found it, I realized that I am 50 pages in and don't remember what I have already read. What a bummer. Hope it wasn't anything important that I didn't already know.

 

On the up side, I only have 12 more days of customer service. Too bad I need the money.  

Tonight I have posted more on this site than any other week in the past. Not that I had anything of interest to say. Perhaps the greatest sin i am capable of commiting online.

 

All your head space are belong to meeez.

 

Since the last time i posted, a lot has happened, including a full frontal digging my first empowerment spam, and some fairly significant site modifications. These make me happy, but I don't see much new content and that makes me sad.

 

Thats the excuse that i'll use. Its been quiet here lately.

So I spent about 3 hours writing a book page for blender 3d. For the first 2 hours, I used Google notebook (eat it security society) then I copied it into empowerment and spent an hour touching it up, formatting, and adding a bit. Next I was going to do a page for Maya and a page for all other 3d modeling apps (there all crap anyway), and I figured I would save myself a few minutes by typing directly into the empowerment dialog. Everything went fine for the first hour or so, the previews looked fine and what not, though I didn't bother to submit/edit, and therefore didn't leave any persistent data. When I accidentally closed the tab (I'm not sure how), it utterly disappeared. "Undo close tab," which I have never had a need for, simply gave me a blank form. Thanks, Firefox, for keeping my session open so that it didn't all go bye-bye. Alas, I have learned. The submit button is right next to the preview button, and edit is nifty. I am going to go party. Damn you Google and Microsoft for making things so easy that I forget even the most fundamental rules of computing. Perhaps I will break my lousy dependence on auto saves tomorrow, but alas, its Saturday night. Time to party.