[development] Node Rendering Debate

[Philippe Jadin]

> Print_r is a fine way to see what variables are
> *available*.  How to assign or create new variables
> and make that data available to the theme is an
> entirely separate and more complicated issue.  And
> that involves knowing what is literally available from
> drupal to assign.  It often leads to having to code
> dive into someone elses module to figure out how to
> get the information you need to print out.

I think the problem is more that modules do not append enough
informations to node. If the informations were available somewhere
inside the node data array, there would be no need to look at the
module sources.

In order to know what is missing for themers, maybe we could ask them
what they *really* need.

imho, what is complicated at the moment when doing a drupal theme, is
the number of layers involved. You can create theme functions that
return html (theme hooks), use an UI to define which fields are shown
(contemplate and others), add some logic to your template, use module
hooks... Often you don't understand where data is coming from.

I'd keep the existing sytem which returns a fully rendered node body
for beginners and provide a super detailed array for advanced use.

By super detailed array, I mean something like this :
(hypothetical book node type with an image cover)

$node->data['title']
$node->data['title']['label'] (as entered in the content type definition UI)
$node->data['body']
$node->data['body']['label']
$node->data['body']['filtered']
$node->data['body']['text']
$node->data['teaser']
$node->data['author']
$node->data['author']['label']
$node->data['author']['id']
$node->data['author']['link']
$node->data['author']['link']['contact_page']
$node->data['author']['link']['profile_page']
$node->data['author']['username']
$node->data['author']['avatar']
$node->data['links']['comments']['label']
$node->data['links']['comments']['link']
$node->data['links']['send']['label'] (added by send to a friend module)
$node->data['links']['send']['link']
$node->data['cck']['cover'] (a custom image cck field)
$node->data['cck']['cover'][0]['title']
$node->data['cck']['cover'][0]['path']
$node->data['cck']['cover'][0]['label']
$node->data['cck']['cover'][0]['width']
$node->data['cck']['cover'][0]['height']
$node->data['cck']['cover'][0]['filesize']
$node->data['cck']['cover'][0]['imagecache']['thumbnail'] (imagecache profiles)
$node->data['cck']['cover'][0]['imagecache']['big']
[...]


If all the content "parts" are available, there is no need to use a
UI. A "themer" module could be created. It would explain what php
snippet must be used to print something inside a node template (ala
devel module).

At the end of the day, themers need to do a few things in their templates :

- check if a variable exists : isset
- loop over an array : foreach
- branch when apropriate : if
- print something : print

No UI will avoid this kind of stuff. A competent themer need to know
and understand those php constructs. The beginner can use CSS + Drupal
administration to do basic theming.

my 0.02

Philippe

> A UI could help the themer have access to more data
> from other parts of Drupal and format it the way they
> want.
>
> I think saying that print_r solves the problem is
> oversimplifying the issue.  We should think about this
> some more.
>