[development] FAPI's future

[Karen Stevenson]

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

We also have many places where we have functions that create sub-form arrays of form elements that are re-used in various places. Well, we have those in contrib for sure, not sure about core. Anyway, I wonder if requiring hook_forms() for every form and sub-form array might be overkill. We really have a variety of things we might want to identify-- simple form elements, more complex collections of form elements that are used in multiple places, and complete forms that are made up of both simple and complex form elements.

Don't we really just need something like hook_info() for forms where these things can announce themselves and provide some metadata? That is sort of what CCK uses to identify available widgets, and I was thinking that that kind of system (hook_info() for form elements) might be something that could be migrated to core.

Karen