[development] FAPI's future

[Jeff Eaton]

On Aug 8, 2007, at 5:47 AM, Dries Buytaert wrote:

> 1. Say I want to build a "submission throttle module".  A user is  
> not allowed to submit more than x forms per hour.  If I want to  
> make this module truly generic, I want to make it configurable.   
> Specifically, I want to compile a list of all the forms in the  
> system, and let the administrator enable/disable the forms that  
> should be added to the pool of forms to be throttled.  For example,  
> I might include the 'create story form', the 'create comment form',  
> the forms of the privatemsg module, and the guestbook module's  
> form.  However, I might want to exclude the search form, and the  
> edit comment form -- I want people to be able to search and edit  
> their comments as much as they want.



>   2. Take the action module.  Right now, we have a hardcoded list  
> of operations that you can attach actions too.  While that's nice,  
> imagine a world where you would be able to attach actions to *any*  
> form.  All of a sudden, I'd be able to tap into the search form,  
> the sending of private messages, the creation of views, the adding  
> of node types.  You name it.

hook_form_alter() can add a #validate and a #submit handler to every  
form that passes its way. Set the per-user per-form throttle count,  
and add a configurable action to the mix, and it's possible. The real  
limitation in this regard isn't FAPI, but the Action system's lack of  
clean configurable conditional support. Even that can be worked  
around by making a standalone configurable action, not unlike the 'if  
a node contains these words...' action.

> The current FAPI does not allow me to build either.  So while we  
> have all the power to manipulate *individual* forms, there are no  
> good tools or mechanisms to introduce tools that operate on a large  
> number of forms.

hook_form_alter catches every form; modules like form_defaults do  
this in a generic fashion and do it really well. The limitation is  
not so much operating on every form, but operating on *select  
subsets* of forms, because there is no central repository that can be  
used to list all the forms in the system.

> For this work, each form needs (i) a human-readable name that can  
> be shown on a configuration page and (ii) all submit buttons  
> require some semantic meta data as well.  Right now, 'Submit' can  
> be both 'create' or 'update'.

This is a good case for hook_forms() being a requirement, not an  
optional mechanism. Right now, users can just call drupal_get_form 
('lovely_delicious_bacon') and FAPI will go about its business  
happily, checking for a lovely_delicious_bacon() function, then  
checkig hook_forms() to see if lovely_delicious_bacon was really  
mapped to my_module_bacon_form().

If we were to make even the simple forms require the use of hook_forms 
(), we would have a very simple transition and an easy place to put  
descriptive metadata. ("What kind of form is this? What module does  
it belong to?" Etc.)

> Specifically, I want to be able to work with forms without having  
> to know anything about them.  I'd like to see us add some semantic  
> metadata to them.  Some of this metadata should be (i) human- 
> readable, some of it should be (ii) machine-readable and (iii) some  
> of it should be both.

This is always going to be tough, and if it works at all it's going  
to be shockingly verbose to work in more than a handful of cases.  
Wouldn't something like fQuery be a better fit? hook_form_alter()  
everything, then scan it for patterns that match...

--Jeff