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