On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian@bryght.com> wrote:
On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote:
This can be overcome with a few simple #validate functions on form elements correct?
There are definitely 2 steps involved here.
widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets.
I don't believe we should include the #validate functions for the field types / widgets into the form structure thought, because if we do it right,. every single field will have validation rules, and all that information will not often be modified (fields can still have additional validation rules of course).
We don't want to bloat the data structure unnecessarily.
Potentially naive question from someone who has not used FAPI to its fullest extent yet: What does hook_widget offer that hook_elements does not? Would it be feasible to simply beef up hook_elements to fill in any missing functionality that hook_widgets has that it doesn't, then deprecate hook_widget? That would give us the bonus of CCK-added fields and form_alter value-add fields both being able to support "rich fields". Instead of a CCK field called "node reference", you'd have a FAPI element called node_reference: $form['other_node'] = array( '#type' => 'node_reference', '#default_value' => $node->other_node ? $node->other_node : 0, '#required' => TRUE, ); And then you could do the same with arbitrarily complex elements/fields which can then be value-added or CCK-added via the admin. Or am I completely misunderstanding hook_elements entirely (which is entirely possible)? --Larry Garfield