[development] FAPI's future

[Dries Buytaert]

*** Dries wrote:
>>> FAPI and the Schema API: next steps (*)
>>>   - A plan to get some more CCK/Views into core (*)

*** Jeff Eaton and chx replied:
>> I do not think we (Eaton+me) will have more ideas for FAPI, all  
>> the common grunts were solved w/ FAPI3, not until D6 is out,  
>> modules are ported and projects are ongoing will the flaws come to  
>> light. Let's get back to FAPI at the spring Drupalcon (Toronto?).
>
> Yep, I'm with Karoly on this one. There are some cleanup bits and  
> things we didn't necessarily have time for in FAPI3 (making  
> form_set_values() and form_set_error() simpler, etc) but those are  
> tweaks and polishing moves rather than architectural shifts.
>
> It will take time, time for porting and exploration and envelope- 
> pushing, to make it clear what changes the next generation will need.

Well, I have some issues still.  Two simple examples:

   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.

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.

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'.

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.

Thoughts?

--
Dries Buytaert  ::  http://www.buytaert.net/