It is no secret that the documentation of the form API is not in great shape. Today Merlin said on IRC that "the design does not lend itself to being well documented" and he is, of course, right. There were proposals during the years to convert everything to object oriented code but IMO that's too much in one fell swoop. I have the idea to use ArrayObject-based objects -- now that #type
matters little -- and keep the current functions -- no methods. The properties will become doxygenable so the documentation is right there in the code, reusable by API module, IDEs etc. Here is some sample code.
So the changes:
- Change
['#foo']
to->foo
- Change
$form['x'] = array('#type' => 'whatever')
to$form['x'] = new DrupalFormWhatever(array(
- Change
foreach(element_children($form) as $key) $child = &$form[$key]
toforeach ($form as $child)
Best of all, most of this change is scriptable -- the first two is likely to be easy with regular expressions, the third IMO needs some more scripting as we usually do $form[$key]...
. First reaction are: Merlin is excited, frando warned that most functions expecting arrays like array_merge wont work which is not ideal but we rarely do operations like that with form children. We now need someone to actually do this right now and then during the long winter of code freeze we can add documentation of the properties.
Commenting on this Story is closed.
Interesting. I had a great/crazy idea for this around .info files
If you need custom essay writing service from professional paper writings team of professional writers you can get it. Our writers can offer resume writing from custom writing service. Only custom papers not internet copys. We write anything.
I recall suggesting ArrayAccess a while back on Barry's blog. It could absolutely be done, and would in fact end up paralleling SimpleXML rather closely if done right, which is a big win.
The problem is that ArrayAccess is not fast. See my benchmarks from last year. While it's more documentable, and frankly I'd much prefer to use classes to hook_elements (or make hook_elements much thinner at least), the performance impact would be highly not-cool, especially when we're already struggling with performance as is. Arrays at least are about as fast as we can get. We're talking 3x slower for every array lookup operation, which in FAPI arrays is several hundred per page. :-(