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