In this screen-cast I plan to show you a new module we are creating called - http://drupal.org/project/form_extended This screen-cast is brought to you by using the Sparkeo video platform - we helped to build
The Drupal form API comes with default generic properties.
The form extended module, lets other modules extend the form API and add their own custom properties.
To create a new form property a module needs to define a plug-able handler. Then each module can use those new properties in it's forms or manipulate other forms using hook_form_alter and Rules form support, on the same way you can manipulate a native property.
This module is still in development and i'll be happy to hear from the community any thoughts and comments they have on the idea itself and its implementation.
-
The implementation of the handlers was build on some of the ideas mentioned in Larry's blog post - http://www.garfieldtech.com/blog/drupal-handler-rfc - Thanks Larry .
3 Comments so far
Having watched the video and also looked at the code in CVS, this makes little sense to me.
The premise here is not quite correct. During the introduction you state, "There is no way to for a module to provide a new property that other modules can use." You can just use hook_elements() to provide this.
function mymodule_elements() {$items = array();
$items['textarea'] = array(
'#autoresize' => TRUE,
'#process' = array('mymodule_process_autoresize'),
);
}
Now the '#autoresize' is available on all 'textarea' elements on the entire site and defaults to TRUE. This module's code seems to imply that the only way of modifying elements is through hook_form_alter(), which is for modifying forms, not elements. Use hook_elements() instead and you affect every element of a specific type, and you don't need to mess with form_alter() at all.
Thanks sun & quicksketch for your replies.
I didn't mean by any way that this is the only way to add custom properties to the form API. The only problem I believe do exists is the lack of standardized mechanism that this can be achieved. I know each element can have its own custom properties (like my examples show), and I do think that the use of OOP is better for this tasks - basically because when defining something global to the site - we too think how can we extended it in the future and inherit form the exiting code. using OOP will also allow the developer to choose its own implementation and can replace existing ones by invoking its own handler.
About the Rules forms support - The rules forms support comes with its own form altering mechanism for native form properties - although the GUI is a bit confusing, it do allows site administer or a new Drupal developer the capability to alter forms without the need of writing a custom module.
About hook_elements - (Thank you for that) I agree that for some added functionality this is the way to go - and maybe i can find a way to add hook_elements to the picture and revise the code a bit.
Post a Comment