The current CVS version of CCK renders all CCK fields into a single large chunk. Drupal 5's node rendering code allows individual fields to be added to $node->content separately. This patch makes it so.

it's rough, and I'm not very familiar with CCK's inner workings, so I'm not sure how clean this solution is. In an ideal world, the 'fields' collection that CCK already builds on node-load could be used.

Any feedback from the CCK-heads in the house?

CommentFileSizeAuthor
#4 content.module_14.patch2.54 KBkarens
#1 cck_rendering_0.patch1.24 KBeaton
cck_rendering.patch1.23 KBeaton

Comments

eaton’s picture

eaton commented
StatusFileSize
new cck_rendering_0.patch1.24 KB

Whoops. a bit of cruft from an earlier version of this tweak snuck in.

karens’s picture

karens commented

Yep, no question we can do better, I just wanted to get something functional committed. And yes, the existing node array should be useful here, using the field weight values that have been broken for so long :-)

Anyone who understands how CCK works is welcome to jump in with suggestions or patches. I plan to take a look at this later if no one else does.

talltim’s picture

talltim commented

Out of interest, will this make it easier to render fields into separate fieldsets or tabs?

karens’s picture

karens commented
StatusFileSize
new content.module_14.patch2.54 KB

I came up with a fairly simple way to incorporate field weights into both the form array and the new content array by making a couple changes to widget_invoke and field_invoke. There are other ways this could be done, but I'm going to post this one as a patch instead of committing it to see if anyone has better ideas or other feedback.

eaton’s picture

eaton commented

Karen, that looks very smooth; thanks for taking a look at this! The 5.0 version is definitely looking good. I can say that the approach you're taking for building the content array is very good, though I can't testify to how well it meshes with existing CCK code. I'll do some additional testing on my end.

In the future, it might be worth noting that the elements in the content array can themselves be themed. The following:

$node->content['my_field'] = array(
  '#type' => 'cck_date_field',
  '#value' => '2004-2-30'
);

... Would by default pass the entire 'my_field' element into them('cck_date_field', $node->content['my_field']).

That's probably overkill at the moment, but the possibility is certainly open in the future.

moshe weitzman’s picture

moshe weitzman commented

As a future enhancement, we could easily offer role based access control on fields using the #access property. we need to enforce this access control on forms and upon viewing cck node.

karens’s picture

karens commented

Is there some documentation somewhere about things like the #type and #access properties and how they work? I couldn't find anything. It would make sense to take advantage of as much functionality as possible, and make sure we're building the array in a way that is as easy as possible for other modules to manipulate the data.

moshe weitzman’s picture

moshe weitzman commented

i don't see docs for those either.

#access is really easy. it is just like the menu system where the valeu is an expression which must be true in order to show the form field or rendered value.

karens’s picture

karens commented
Status: Needs review » Fixed

I went ahead and committed this. It's a pretty simple fix that shouldn't break anything else and it uses the field weights which have never worked right and also gets the content array into a format that it can be accessed and manipulated by other modules to add other features, like field level access control. I'm also going to alter the 4.7 version with the change to the form array, since that part of this fix will work in that version.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
kenorb’s picture

kenorb commented

http://drupal.org/project/contemplate