Exposed forms as plugins

+++ views.module	18 Aug 2009 15:54:41 -0000
@@ -972,7 +972,7 @@ function views_exposed_form(&$form_state
-    '#value' => t('Apply'),
+    '#value' => t($form_state['submit_button']),

Why not let this be handled by the plugin. There could be perhaps a dynamic submit button, but there shouldn't be this string in the locale_source table.

+++ plugins/views_plugin_display.inc	18 Aug 2009 15:54:52 -0000
@@ -1547,6 +1636,29 @@ class views_plugin_display extends views
+          $plugin->options_submit($form['exposed_form_options'], $form_state);
+          krumo($form_state['values'][$section]);
+++ plugins/views_plugin_exposed_form.inc	18 Aug 2009 15:54:52 -0000
@@ -0,0 +1,96 @@
+  function option_defaults(&$options) {
+    $options['submit_button'] = t('Apply');

needs to be removed before commiting the patch.

+++ plugins/views_plugin_exposed_form.inc	18 Aug 2009 15:54:52 -0000
@@ -0,0 +1,96 @@
+  function option_defaults(&$options) {
+    $options['submit_button'] = t('Apply');

So currently the submit button value is handled full by the plugin. This would cause currently apply be translated to "foo". And then t("foo") will be called again.

This review is powered by Dreditor.

Just tagging to views 3.x

Despite a couple of small problems, I'm tempted to go ahead and commit this. This is something I like a lot. Great work!

1) There's a leftover krumo() statement.
2) The option_defaults() is outdated and needs to be pulled from everywhere. Go with the option_definition() pattern used in styles and row styles instead. That is more robust.
3) Let's give the "Exposed" options their own category in the UI. I plan to re-org this stuff a little anyhow.

The fact that we need option_definition as opposed to option_defaults is the only thing preventing me from just committing it now; that's going to be a pain to go back and fix. So let's fix that, then I can commit it.

Cleaned up a bit and committed. Patch attached because this needs to be ported.

I think that patch is missing the plugin class files; they'll have to be pulled from the 6.x-3.x branch.

Here is the first part. The settings of the exposed forms, are not displayed currently.

The plugins are included in the patch.

@Dagmar:
This is part of the current drupal6 _on_demand exposed form plugin. I don't do anything here.

New version:

- Current problem:
Exposed_input is sometimes returns as array() sometimes as $value.

Here is a example view to reproduce this.

$view = new view;
$view->name = 'frontpage';
$view->description = 'Emulates the default Drupal front page; you may set the default home page path to this view to make it your front page.';
$view->tag = 'default';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('sorts', array(
  'sticky' => array(
    'id' => 'sticky',
    'table' => 'node',
    'field' => 'sticky',
    'order' => 'DESC',
  ),
  'created' => array(
    'id' => 'created',
    'table' => 'node',
    'field' => 'created',
    'order' => 'DESC',
    'relationship' => 'none',
    'granularity' => 'second',
  ),
));
$handler->override_option('filters', array(
  'promote' => array(
    'operator' => '=',
    'value' => '1',
    'group' => 0,
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => FALSE,
      'operator' => '',
      'identifier' => 'promote',
      'label' => 'Promoted to front page',
      'remember' => FALSE,
      'single' => TRUE,
      'optional' => FALSE,
    ),
    'id' => 'promote',
    'table' => 'node',
    'field' => 'promote',
  ),
  'status' => array(
    'operator' => '=',
    'value' => '1',
    'group' => 0,
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => FALSE,
      'operator' => '',
      'identifier' => 'status',
      'label' => 'Published',
      'remember' => FALSE,
      'single' => TRUE,
      'optional' => FALSE,
    ),
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('use_pager', '1');
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'teaser' => 1,
  'links' => 1,
));
$handler->override_option('exposed_form', array(
  'type' => 'basic',
  'options' => array(),
));
$handler = $view->new_display('page', 'Page', 'page');
$handler->override_option('path', 'frontpage');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
));
$handler = $view->new_display('feed', 'Feed', 'feed');
$handler->override_option('title', 'Front page feed');
$handler->override_option('style_plugin', 'rss');
$handler->override_option('style_options', array(
  'mission_description' => 1,
  'description' => '',
));
$handler->override_option('row_plugin', 'node_rss');
$handler->override_option('row_options', array(
  'item_length' => 'default',
));
$handler->override_option('path', 'rss.xml');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
));
$handler->override_option('displays', array(
  'default' => 'default',
  'page' => 'page',
));
$handler->override_option('sitename_title', '1');

Ah ok. thanks for this information.

Sorry, dagmar admitted he wasn't sure On Demand was right, so I changed it as I worked on it. I also really dislike adding WHERE clauses to the query to force it to produce an invalid result, and instead made sure that there is a way to abort the query by setting a value in the build info.

Together with http://drupal.org/node/652716#comment-2348648 it works as expected.

Its from my perspective rtbr

So here is combined patch with the patch above.

This patch is quite important because there are many many issues which needs this patch

Updated version

Some files missed

Oh, i forgot the remove the other one. As you see in the patch, i have both input_required, but also on_demand


Change t('Apply') for 'Apply'

This was part of the original commited version see http://drupalcode.org/viewvc/drupal/contributions/modules/views/plugins/views_plugin_exposed_form.inc?r1=1.1&r2=1.1.2.1

The same answer applies to the next 3 reviews.

The last:
Damn i got confused by the names, i remove the wrong file :)

Updated version

Next version

I missed a render call

Thanks dagmar for the testing and finding bugs again :)

http://drupal.org/cvs?commit=306686