[development] Freezing the Drupal API

[Adrian Rossouw]

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