*** 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/