On 16 May 2006, at 3:24 AM, Richard Archer wrote:
I would also argue that the lack of a robust API has a detrimental effect on the quality of the code in Drupal. For a simple example, trace through the code that displays a menu item and see how much code is executed to perform this task! I think this is a good example of where "code is gold" and not having a well-defined API to work within has led code which is complex, convoluted and inefficient.
I'm going to step in here and post what I hope to be possible with FAPI 2.0 Fapi is still remarkably badly named, because it's not really what it's about. In FAPI 2.0, you define the form fields, separately from the form elements (ie: widgets). You can have multiple forms, or output view, based on the same set of fields (ie: different views of the same model). Additionally, you get multiple actions that can be executed on that same model (ie: the controller, or the _submit functionality). Due to the separation of the forms / actions from the page model, we will no longer have to generate the entire page, and then do the form_builder process to extract the field definitions. All models, views and controllers will have be accessible through a path (ie: the user login form can be retrieved by doing drupal_get_form('user/login'); , without having to create an array and push it through the entire process. It will just pull what it needs, when it needs it. It's also an implmentation of the Command Pattern (http:// en.wikipedia.org/wiki/Command_pattern), but where it gets really interesting is the following. Every thing that drupal can do via a form, drupal can do through a standard programmable interface. Take the following for example : $request = drupal_get_request('node/add/event'); $request['title'] => 'something'; $request['body'] => 'something'; $result = drupal_send_request('node/add/event', $request); What this does, is it gets the correct model(s) for that specific action, then it allows you to populate the variables, however you want. And then when you send the request, it goes back through the original form _validate, and finally hits the original _submit. This can be done for any form, that you have sufficient access to, and each of these actions can then be publicly exported via ReST, xmlrpc, soap, you name it. What it essentially does is create a standard API for everything to use, and for that reason I've been joking with calling it the API API or API ^ 2.0 -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com