I've been experimenting with implementing complex fields by creating a field type that's also a fieldable entity.
But I've run into some problems in the form department. The issue is that $form['#fields'] makes it rather difficult to include a field in a complex element, when field implementations expect the form global #fields to include the the field and instance. It's 'just' form API #process functions that seems to be the problem.
I'd rather not have all fields (complex or regular) in $form['#fields'] because it makes impossible to have the same field as part of the (say) node and a complex field, or part of 2 different complex fields on the same node. Which limit their usability quite a bit.
However, in text.module, I found this in the comment on the process function:
<?php
/*
* The $field and $instance arrays are in $form['#fields'][$element['#field_name']].
*
* TODO: For widgets to be actual FAPI 'elements', reusable outside of a
* 'field' context, they shoudn't rely on $field and $instance. The bits of
* information needed to adjust the behavior of the 'element' should be
* extracted in hook_field_widget() above.
*/
?>Which indicates that there's a wish to make widget #process functions independent of $form['#fields']. That would seem to fix my problem, as the hook_field_widget gets handed the correct field and instance, and doen't have to muck about in the $form to find them.
Is this the case, and can I make myself useful by creating patches to make field process functions independent of $form['#fields']? I know that field.module itself uses $form['#fields'], which I have to take into account for complex fields, but is there any good reasons why widgets should use it?
Comments
I have absolutely no
I have absolutely no certainty that a "fieldable field" (or rather "a field type whose values are fieldable entities", I guess ?) is the right approach or will work in the end, but it is certainly worth exploring.
As for the part about cleaning widgets FAPI code of all direct references to $field or $instance : sure, it would be a great cleanup. http://drupal.org/node/362058 is open for this. You're very welcome to take this task.
"...is the right approach or
"...is the right approach or will work..."
Well, I figure it can be made to work, it's just a question of effort. WRT whether it's the right approach, I haven't seen any alternatives that attempt to solve the same problem, that doesn't have it's own set of problems.
"http://drupal.org/node/362058 is open for this. You're very welcome to take this task."
Excellent. Digging around in those parts will give me a better feel for things.
Should $form['fields'] be considered field.module private?
At DCDC I started down the
At DCDC I started down the road to making a field type that is a fieldable entity. I think it is a promising approach. I recall being confident that I knew how to make "combo fields" that work provided each sub-field of a combo field has a fixed cardinality, but could not think of a good general solution for a combo field that contains a sub-field of unlimited cardinality. The problem was that if the combo field itself was unlimited cardinality, there was a problem lining up which unlimited-cardinality sub-field values belong to each combo field. OR something like that.. I haven't had time to think about it since the days after DCDC.
But anyway, I definitely support your going down this path and look forward to what you come up with. :-)