If you like this idea, I can spend some time on it and submit a patch. Let me know.

The idea is to provide a way for admins to define templates for CCK node types. Templates would be defined on admin/node/types/content-my_node_type (or a tab beneath that page). Two templates could be created, one for teaser and one for regular view. If defined, the template would control what is returned by content_view().

Let's say the node has a text description, and an assigned user. A template might look like:

<p>This issue is assigned to: %field_assigned_user</p>
<div class="issue_description">
%field_description
</div>

In content_view, the keywords "%field_assigned_user" and "%field_description" would be substituted with the node specific values. (It would build an array by calling the appropriate hook_field('view'...) methods, then call t() to substitute).

The templates would be stored as new columns in the node_type table. (Any reason that table does not have a node type ID? Is the type_name guaranteed to be unique?)

The goal is to provide a way to customize output through the same interface used to define the content. Also without relying on naming conventions to work (i.e. if I change my content type from "my_node_type" to "my_node_type2", then node-my_node_type.tpl.php will no longer be used). Of course if you need something complicated like php code in your template, this feature would not help you. Note that the templates I'm describing are not equivalent to node-my_node_type.tpl.php which displays things like title, links. The templates I'm talking about would only cover what node.tpl.php refers to as $content.

Comments

seandunaway’s picture

can't we already do this with phptemplate and node-contenttype.tpl.php?

Dave Cohen’s picture

The more I think about this, the more I realize that a theme is the place for templates/code that customize the display. Because in the end, each theme should be able to do it differently.

However, I think CCK needs to be more theme-friendly. All the display code in hook_field('view',...) seems to be un-themeable. For instance where text_field() calls:

        return '<div class="'. $field['field_name'] .'">'. $node_field['view'] .'</div>';

It should really call:

        // $value is text, $label is human readable label, $field_name is $field['field_name']
        return theme('content_text_field', $label, $value, $field_name);

In the case of a text field, a theme may never need to change the default theme. But in the case of say a user reference customization is more likely. Userreference does not inject the 'view' element into $node->$field the way text.module does. So in my node-content_my_type.tpl.php I had to do this:

<?php if (count($node->field_assigned_to) && 
          ($assignee = $node->field_assigned_to[0])) { ?>
  <dl class="assigned_to">
    <dt>Assigned To</dt>
	<dd><?= theme('username', user_load(array('uid' => $assignee)))?></dd>
  </dl> 
<? } ?>

Ugh. Life would be much better if I could simply define

function mytheme_content_userreference($label, $value, $field_name) {
  // $value is array of uids
  // theme code here...
}

And finally, content_view() could call something like theme('content_node', ...) instead of simply implode(_content_field_invoke('view', $node, $teaser, $page)).

If CCK went to the trouble of all that, then users could customize display on a number of levels (each field type and/or all CCK node types and/or each CCK node type).

KarenS’s picture

Did you see my suggestion/patch at http://drupal.org/node/55338? I took a different approach so that each field could be wrapped in whatever element you want before sending it back to the node. Once wrapped, you can easily theme it, apply css, etc. The patch won't work on the latest version of the code since everything got changed, (at least I am not sure it will work any more), but the basic idea was to add options when you create a field about how you want it sent back to the node (in a label and a div, in a dt and a dd, without a label, etc.). I think it would make more sense to set that kind of thing up when the field is created rather than adding in every possible field to a tpl file. That way each field can create something that makes sense for the specific kind of data involved.

Dave Cohen’s picture

I had not seen that - thanks for pointing it out. I like it a lot. Mostly, I like it for making things much more theme-friendly.

In principle, deciding whether to use a <dd> vs a <div> should not be in the content admin pages, it should be in themes. However, its very tempting to add it where you have, for most people's ease of use.

JonBob’s picture

Status: Active » Fixed

The theming system is much more robust now, and all hard-coded HTML has been removed. Instructions and examples are provided in the "theme" subdirectory of the project.

Anonymous’s picture

Status: Fixed » Closed (fixed)