[development] proposal for theming nodes

[Adrian Rossouw]

On 14 Dec 2005, at 6:28 PM, Jose A. Reyero wrote:
> The ideal would be using both, themeable functions that produce
> structured data, but any of them used separately would just fix the
> problem. However, the way to go, thinking big, would be kind of
> 'generalized form API' that could be useful to build any object -page,
> block, node..- as structured data and then render it to HTML.

I didn't get the original mail for this thread .. but i'll throw my  
2c in here.

The forms api is not really a forms api .. it's a structured way of  
driving the theme
system with arrays.

Realistically, we will need to use the forms api to output nodes  
generated with
CCK (something it was designed to do) , and I plan to introduce this  
for themeing
at the very least, all nodes .. but possibly even more output.

The forms api is basically a kind of model / view / controller  
system , except
in the current implementation .. the structure of the model and the  
view are
merged. Which is .. incredibly .. not ideal (it also wasn't my call).

We need to separate out the actual variables needed, into their own  
function
(ie: getting rid of all that horrendous '#tree' logic, and actually  
just defining the two
trees separately). We also define the actual type of the variable  
(ie: integer, blah),
wether they are optional or not. etc, which ties into the validation.  
This is the level
where CCK would get integrated.

Then each model, can have multiple views. Only one of these views is  
a form.
Thus we introduce another function which places all these variables  
defined, into
a new structure (ie: adding fieldsets, and tables etc)

Then this final structure gets either rendered by the theme system, or
gets rendered by the default render() function, which knows how to  
traverse
trees and call theme functions.

Each element has a default theme function, but can also have a  
specific theme
function used for a specific view. Basically so the default theme  
functions for
all views would be to display the text / image / whatever, but the  
form view
will have use the <input> theme elements.

This means that adding a  file element to the form could  
automatically render a file link
(or an image if it's an image element), but render a file input  
dialog in the form view.

A lot of the complexity related to the form system is due to the  
(probably correct)
decision to not get into the menu system at that stage of the  
development ..
,but the major hurdle of transition is almost over, and there are  
enough benefits
to the current system to live with it for a while, but the next phase is
where it will truly shine (and become a _lot_ cleaner).



--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com