Download & Extend

Separate include files for form alters.

Project:Omega
Version:7.x-4.x-dev
Component:Feature Request
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

Prompted by a blog post about Omega 4, I am creating this to discuss the possibilities about providing an include mechanism for form alters.

A simple (naive?) solution is to implement a global form alter, and then do something similar to the alpha_invoke() function in Omega 3.x. A simplified (non-working code, just for discussion) version would be:

function omega_form_alter(&$form, &$form_state, $form_id) {
  $key = $GLOBALS['theme_key'];

  $function = $key . '_form_' . $form_id . '_alter';

  if (!function_exists($function)) {
    $file = drupal_get_path('theme', $key) . '/form/' . $form_id . '_alter.inc';

    if (is_file($file)) {
      include $file;
    }

    if (function_exists($function)) {
      $function($form, $form_state);
    }
  }
}

However, this would hit the filesystem about a billion times, so performance would suffer. I think this also violates some execution ordering with what is normally expected with forms and drupal_alter().

The primary complication is that Drupal doesn't provide a way to get all forms that the system defines.

Perhaps a compromise would be to to scan for .../form/form.alter.inc in omega_theme_registry_alter() and allow users to place all form alters in a single include? Not ideal, but it would help keep template.php lean.

Thoughts?

Comments

#1

Performance is indeed a major concern here. For preprocess/process and theme hooks that's handled nicely by the theme registry and omega_theme_registry_alter() which pre-scans for files that match a certain pattern and hook name. However, for form alters we really have no way to do anything similar. Of course we could cache manually after another file scan for foo.form.alter and then invoke those from omega_form_alter($form, $form_state, $form_id) but that means we will get useless function calls most of the time (whenever there was no form_alter provided).

So... Regarding the patch: This is what we used to do, yes... But it was bad... and slow. We can't commit anything like that without serious db and static caching.

However, this would hit the filesystem about a billion times, so performance would suffer. I think this also violates some execution ordering with what is normally expected with forms and drupal_alter().

Yes... That. Execution order would be affected in some cases. We don't want that either. I am currently a bit in doubt that we will be able to find a solution that works in a nice, and well-performing way without altering execution order, etc. ...

Looking for a form.alter.inc also wouldn't be something I would put into Omega directly because, well, you can just do that manually in your subtheme's template.php anyways. :)

I will look at drupal_alter() later and see if we can inject our stuff somewhere into the bootstrap cache. But don't get your hopes too high :(.

I like the idea though... :)

#2

Thanks. I spent some time looking into the feasibility before I posted to see if I could provide a patch, and realized it is a long shot. However, I wanted to throw it out there in case someone more familiar with the mechanics of the registry and drupal_alter() would have an idea.

#3

Status:active» closed (won't fix)

As great as this would be, this would be quite detrimental to performance so I think it's a no go.