Not all forms need to be generated dynamically. There many cases in which a form will be the same for all inputs.
Yet, there are some forms that will require varying default values for a common set of fields.
So, many forms may be presented quickly without program execution for every use.
The following code snippet provides a high level outline of a way in which forms may be processed in order to achieve the higher throughput.
This is a change of drupal_render_form, where the change is only to code around drupal_render. As such the change could be implemented in any version after five, without affecting other aspects to mechanisms of form retrieval.
I have used the approach of just getting forms for a subclass of data in classydex,, www.classydex.com. These forms are all very similar. They can bring in their own CSS and can contain information about payment or not, etc. The retrieval of the forms is fairly rapid. I found that getting javascript for the entry was more difficult and that it was best to have each javascript dependency in a form already available on the page in which the form is made to reside. However, note that for classydex, forms are retrieved in response to Ajax calls while forms generated below are in the Drupal page context.
/**
* Renders a structured form array into themed HTML.
*
* @param $form_id
* A unique string identifying the form for validation, submission,
* theming, and hook_form_alter functions.
* @param $form
* An associative array containing the structure of the form.
* @return
* A string containing the path of the page to display when processing
* is complete.
*/
function drupal_render_form($form_id, &$form) {
// Don't override #theme if someone already set it.
if (!isset($form['#theme'])) {
init_theme();
$registry = theme_get_registry();
if (isset($registry[$form_id])) {
$form['#theme'] = $form_id;
}
}
$output = "\n<div id='panelbar'>\n";
$formtext = "";
if ( !changed_form($form_id,$form) && !dynamic_form($form_id,$form) ) {
$formtext = fetch_prerendered_form($form_id); // As in get it from the DB..
if ( is_array($formtext) ) { // If this form still needs information loaded into it
$formtext = transfer_default_substitutions($formtext,$form); // Transfer default values in substitution entries. Return string finally...
}
}
if ( $formtext != "" ) { // Render it at least once.
$formtext .= drupal_render($form);
// Ask this question: Does this form now need to be stored? (Cache the form, put it into the DB.)
if ( form_to_be_cached($form_id) ) {
store_this_form($form_id,formtext);
}
}
$output .= "\n</div>\n";
return $output;
}
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | formdb.inc_.tar_.gz | 529 bytes | rleddy |
Comments
Comment #1
rleddy commentedI just tried this out.... And, I corrected the error in the posted code.
SO, for 5.x here is another version of the subroutine...
In order to make this code work, I made a new file to put in the include directory.
The file is attached, and it requires the following DB definition:
An example of use is the following:
Oddly, this example works for a form that seems to be very dynamic. But, in truth, the form variability is determined by javascript parameters and not the actual form HTML.
So, as a result, even a highly dynamic form can be rendered just once. Of course, there are many lists, e.g. search results which require new forms every time.
Comment #3
dpearcefl commentedIs there any interest in this issue any longer?
If so, the need should be evaluated against D8.