[development] proposal for theming nodes
adrian at bryght.com
Wed Dec 14 17:06:19 UTC 2005
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
CCK (something it was designed to do) , and I plan to introduce this
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
merged. Which is .. incredibly .. not ideal (it also wasn't my call).
We need to separate out the actual variables needed, into their own
(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
Thus we introduce another function which places all these variables
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
trees and call theme functions.
Each element has a default theme function, but can also have a
function used for a specific view. Basically so the default theme
all views would be to display the text / image / whatever, but the
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
decision to not get into the menu system at that stage of the
,but the major hurdle of transition is almost over, and there are
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).
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development