One of the final pieces I would like in Views 3.x is the view as form. What this means, to me:

1) It's probably a style that presents a form.
2) It opens up special fields that are 'form' fields and allow input tied to specific fields.
3) There are form plugins that control what the form does.
a) Views Bulk Operations would be retooled to one of these plugins
b) Mass node edit would be the other stock form plugin

A big component of this will be writing the CCK side so that we can mass edit CCK fields, but if we can do core + CCK fields initially, other modules can catch up and also provide their fields as form fields.

We can then expand to mass editing of other objects (users, primarily).

Files: 
CommentFileSizeAuthor
#31 form_id_with_args-769322-26-p0.patch300 byteswillvincent
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch form_id_with_args-769322-26-p0.patch. Unable to apply patch. See the log in the details link for more information. View
#26 form_id_with_args-769322-26.patch314 byteswillvincent
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#22 769322-6x-followup.patch2.58 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6x-followup.patch. Unable to apply patch. See the log in the details link for more information. View
#22 769322-7x-followup.patch2.84 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-7x-followup.patch. Unable to apply patch. See the log in the details link for more information. View
#20 interdiff-7.patch4.57 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-7_0.patch. Unable to apply patch. See the log in the details link for more information. View
#20 interdiff-6.patch5.75 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-6_0.patch. Unable to apply patch. See the log in the details link for more information. View
#19 769322.patch14.62 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_5.patch. Unable to apply patch. See the log in the details link for more information. View
#19 769322-6.patch15.42 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_4.patch. Unable to apply patch. See the log in the details link for more information. View
#19 views_form_example.zip4.4 KBbojanz
#18 perf-7.patch3.17 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch perf-7.patch. Unable to apply patch. See the log in the details link for more information. View
#16 views_form_example.zip4.91 KBbojanz
#16 769322-6.patch15.02 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_3.patch. Unable to apply patch. See the log in the details link for more information. View
#16 769322.patch14.18 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_4.patch. Unable to apply patch. See the log in the details link for more information. View
#9 769322.patch14.04 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_3.patch. Unable to apply patch. See the log in the details link for more information. View
#9 769322-6.patch14.93 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_2.patch. Unable to apply patch. See the log in the details link for more information. View
#8 769322.patch14.01 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_2.patch. Unable to apply patch. See the log in the details link for more information. View
#8 769322-6.patch14.88 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_1.patch. Unable to apply patch. See the log in the details link for more information. View
#7 769322-6.patch15.03 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_0.patch. Unable to apply patch. See the log in the details link for more information. View
#7 769322.patch14.16 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_1.patch. Unable to apply patch. See the log in the details link for more information. View
#7 views_form_example.zip3.27 KBbojanz
#5 769322-6.patch8.55 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6.patch. Unable to apply patch. See the log in the details link for more information. View
#3 769322.patch9.5 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322.patch. Unable to apply patch. See the log in the details link for more information. View
#4 769322.patch9.54 KBbojanz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_0.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

kenorb’s picture

+1

EvanDonovan’s picture

Oooh...this is exciting.

bojanz’s picture

FileSize
9.5 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322.patch. Unable to apply patch. See the log in the details link for more information. View

As Earl suggested, providing views_form as a patch, since it does exactly what is described here.
Needs an advanced help entry (can be just what I wrote in the README for views_form).
And testing with 6.x-3.x, I only used it with 7.x-3.x (VBO Reloaded is using it happily).

bojanz’s picture

Status: Active » Needs review
FileSize
9.54 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_0.patch. Unable to apply patch. See the log in the details link for more information. View

Tweaked the hook bodies in views.api.php

bojanz’s picture

FileSize
8.55 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6.patch. Unable to apply patch. See the log in the details link for more information. View

Here is a completely untested, not yet working 6.x version.

However, this part can't work:

+    $form = drupal_get_form(views_form_id($view), $view, $vars['rows']);
+    // The form is requesting that all non-essential views elements be hidden,
+    // usually because the rendered step is not a view result.
+    if ($form['show_view_elements']['#value'] == FALSE) {
+      $vars['header'] = '';
+      $vars['exposed'] = '';
+      $vars['pager'] = '';
+      $vars['footer'] = '';

Since drupal_get_form() returns a rendered form :/ The only thing I can think of is searching for 'div class="views-form"' in the output.
Any other ideas?

To be honest, not sure how important a 6.x version even is, since all our use cases are 7.x (VBO, editablefields, Drupal Commerce, Commerce Affiliate) and I don't think anyone will be doing many 6.x rewrites at this point of it's life cycle.

merlinofchaos’s picture

In D6, ctools_build_form can can $form_state['want form'] and get an unrendered $form array back, and then Views could do the rendering later.

Obviously this could only work if CTools were available, so that's not the best solution. however, making this a limited feature in D6 is not completely terrible.

bojanz’s picture

FileSize
3.27 KB
14.16 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_1.patch. Unable to apply patch. See the log in the details link for more information. View
15.03 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_0.patch. Unable to apply patch. See the log in the details link for more information. View

6.x-3.x patch
7.x-3.x patch
D6 example module

Advanced help & pure awesomeness included.

bojanz’s picture

FileSize
14.88 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_1.patch. Unable to apply patch. See the log in the details link for more information. View
14.01 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_2.patch. Unable to apply patch. See the log in the details link for more information. View

Had one too many reference symbols in (views_form_validate and views_form_submit), caused a deprecated warning on PHP 5.3.
Also killed the comment, it confuses more than it clarifies.
All fixed now.
Reported by the first VBO Reloaded user :)

bojanz’s picture

FileSize
14.93 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_2.patch. Unable to apply patch. See the log in the details link for more information. View
14.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_3.patch. Unable to apply patch. See the log in the details link for more information. View

Another set of tweaks.
Replaced the "This function was sponsored by the Department of Redundancy Department." views_form_views_form comment with something actually useful, didn't even notice that it survived all the way from the initial views_form iteration.
Fixed the advanced help formatting (didn't use html entities for < and > in the code sample...)
Replaced incorrect mentions of $form_state['step'] with $form_state['storage']['step'] in a few D6 comments.

infojunkie’s picture

+100000

Shadlington’s picture

Subbing

bojanz’s picture

Working good so far in production (VBO and editablefields. Will patch Commerce to use it as well when the patch lands).

A future improvement would be to implement a callback for multiple step forms, so for example when VBO shows the config form or confirmation screen, the view itself isn't built, executed, rendered for no reason (since it's not actually displayed).

dawehner’s picture

Some questions


+function views_form_validate($form, &$form_state) {
+  foreach (module_implements('views_form_validate') as $module) {
+    $function = $module . '_views_form_validate';
+    $function($form, $form_state);
+  }
+}

Doesn't module_invoke_all works here?


+  $hooks['views_form_views_form'] = $base + array(
+    'render element' => 'form',
+  );

Does render element exist for 6.x as well? Not sure here.

+  foreach ($substitutions as $placeholder => $substitution) {
+    $search[] = $placeholder;
+    $replace[] = $substitution;
+  }

We could reduce it by using array_keys($substitutions) and array_values($substitutions) but keep the extra variables for better readability. Sure this would have to be moved up some lines in the code.

+      $vars['header'] = '';
+      $vars['exposed'] = '';
+      $vars['pager'] = '';
+      $vars['footer'] = '';
+      $vars['more'] = '';
+      $vars['feed_icon'] = '';

Since display extenders perhaps some people would like to use other variables, too, but i'm not sure how to provide a more flexible mechanism here.

+    $field_name = $this-&gt;options['id'];
+    foreach ($form_state['values'][$field_name] as $row_id => $value) {
+      if ($value == 'Bojan') {
+        form_set_error($field_name . '][' . $row_id, "You can't be named Bojan. That's my name.");
+      }
+    }
+  }

Nice :)

+  function views_form($form, $form_state) {
+    // The view is empty, abort.
+    if (empty($this-&gt;view-&gt;result)) {
+      return $form;
+    }

I'm wondering whether $form should be a reference.

If some kind of views form implementation needs some settings what do they do?

dawehner’s picture

Just a short cross-reference, which is somehow required to test this patch http://drupal.org/node/1165164

bojanz’s picture

Doesn't module_invoke_all works here?

No. module_invoke_all() doesn't allow you to pass params by reference, which is vital for us ($form_state).
There was a comment above explaining that, I killed it, maybe I should bring it back?

Does render element exist for 6.x as well? Not sure here.

Good question. Everything seems to be working, but I'll check.

Since display extenders perhaps some people would like to use other variables, too, but i'm not sure how to provide a more flexible mechanism here.

The variable unsetting might be avoidable by implementing the callback for other steps of the form. We'll see.

I'm wondering whether $form should be a reference.

Makes sense.

If some kind of views form implementation needs some settings what do they do?

Since views form goes through handlers, they can just declare the options there (option_definition / options_form). That's what VBO does.

And the "Bojan" example is leftover from the initial test code, can probably be something more neutral :P

bojanz’s picture

FileSize
14.18 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_4.patch. Unable to apply patch. See the log in the details link for more information. View
15.02 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_3.patch. Unable to apply patch. See the log in the details link for more information. View
4.91 KB

Here we go again. D7 patch, D6 patch, D6 example module.

Changes since last time:
1) Added a comment to clarify why module_invoke_all() isn't used
2) Made the form modified by reference. Committed the same change to views_form (the module) and VBO reloaded, so VBO can still be used for testing.
3) Made the examples in advanced help more generic.
4) Removed the 'render element' line from the D6 patch, it was not used, as dereine suspected.

I gave up on the "custom callback" idea for now. It's complexity for only one use case, and should probably be given more thought.
The idea is that VBO would benefit from not executing & rendering a view that's not displayed (in the config and confirm steps).

Also, I think the unsetting of $vars can be left as is. We are unsetting the elements outputted in the views-view template. If a display extender or any other code adds more elements, they will need to change the template file as well. Probably not something that should concern us.
Alternatively, we can just kill all $vars other than "rows", "classes", and "dom_id" (might have missed some).

zabelc’s picture

Subscribe. Looking forward to seeing this in the posted dev release, so I can use it with VBO rules actions!

bojanz’s picture

FileSize
3.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch perf-7.patch. Unable to apply patch. See the log in the details link for more information. View

Here's a proposed performance improvement (by DamZ). Only works for D7 right now (D6 doesn't fire $form['#process'] ?!)

EDIT: Ignore this. The right solution is not to pass $view to the theme function at all. I have a patch working, coming right up...

bojanz’s picture

FileSize
4.4 KB
15.42 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6_4.patch. Unable to apply patch. See the log in the details link for more information. View
14.62 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322_5.patch. Unable to apply patch. See the log in the details link for more information. View

Here's the new version.
No longer stores the view object for the second time.

bojanz’s picture

FileSize
5.75 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-6_0.patch. Unable to apply patch. See the log in the details link for more information. View
4.57 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-7_0.patch. Unable to apply patch. See the log in the details link for more information. View

Also, the interdiffs.

Let's get this in, and further polish if needed can always be a followup. Lots of nice things are waiting on this patch.

dawehner’s picture

Status: Needs review » Fixed

Great. Looked at played a bit with it. Commited to 7.x-3.x and 6.x-3.x

If there are additional things to be done it can be done later.

bojanz’s picture

Status: Fixed » Needs review
FileSize
2.84 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-7x-followup.patch. Unable to apply patch. See the log in the details link for more information. View
2.58 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 769322-6x-followup.patch. Unable to apply patch. See the log in the details link for more information. View

Here is a followup that makes the Commerce use case possible.

It makes it possible for header / footer area handlers to implement views_form() as well, adding what they need to the form (making it possible for something to appear above / below the main output, table for example). An additional required function is views_form_empty($empty) that returns a boolean saying whether there's any output (if it returns FALSE, views_form() is not called). That allows the handler to examine its "Display even when the view is empty" option and act accordingly.

Could use a few lines in advanced help, but that can another followup.

dawehner’s picture

Status: Needs review » Fixed

Review looks fine. Commited to 6.x-3.x and 7.x-3.x

AndrzejG’s picture

Where can I find this functionality in UI as the site admin (7.x-3.0-rc1)?

bojanz’s picture

There is no functionality in the UI (other than the help page, of course).

willvincent’s picture

Status: Fixed » Needs review
FileSize
314 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

I'm working on a commerce project that requires multiple cart instances to appear on a single page. The problem with this is that the way the form id's are currently generated, more than one instance of the form cannot be on the page and fully functional.

To clarify, the forms show up correctly, but any operations attempted on the nth form (anything beyond the first form displayed) affects the first form, rather than the form the operation was attempted on.

The simple solution to this is to include any arguments that are passed to the view as part of the form id.

Obviously this wouldn't work if there were a view that did not accept any arguments, but in that case I can't imagine a need to embed multiple instances of the form, and even so since without arguments the result set would be the same, if an operation on a second or third instance of a form would result in the same behavior as performing that operation on the first instance of it.

I've included a patch here for your review. This patch has successfully resolved the issue I was having, and should be able to handle views with any number of arguments (or none at all).

bojanz’s picture

Why not just have a different display per view instance? The arguments approach doesn't sound very good to me.

willvincent’s picture

There's no way that will work for this use case. I'm working on a project that requires a separate cart/organic group. All of which have to be visible on a single page. It's not realistic to even attempt to create that many view displays.

Why does this not sound like a good solution?

Can you elaborate on why this doesn't sound good? It doesn't break anything, and it certainly adds a great deal of functionality.

mstrelan’s picture

@bojanz - you keep mentioning editablefields here, and 7.x, but I can't find a 7.x release for editablefields except Damz sandbox, which doesn't seem to work too well (eg editing multiple fields for one node, requirement for many save buttons per view). Is there another release somewhere or is this what you're referring to? Or are you talking D6?

bojanz’s picture

@willvincent
Okay, good point, let's consider the arguments approach then.

@mstrelan
Looks like DamZ still hasn't committed the new code to his sandbox. I'll remind him.

willvincent’s picture

FileSize
300 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch form_id_with_args-769322-26-p0.patch. Unable to apply patch. See the log in the details link for more information. View

drush make doesn't currently support p1 patches, so here's a version of my patch from #26 in the p0 format.

EndEd’s picture

subscribe

omercioglu’s picture

sub

kenorb’s picture

How to test "View as form" style feature?

mstrelan’s picture

@kenorb

Download one of these modules

Or read the views advanced help page on forms, then implement your own handler.

infojunkie’s picture

@kenorb: I also wrote about this feature - the post discusses an example plugin.

latulipeblanche’s picture

subscribe

SocialNicheGuru’s picture

I am confused about the usage of this feature.

I can add fields as usual to my view. I don't want to create a new handler if I do not need to.

But then how do I enable the form? I see #34 through #37 but I am still at a loss.

Could anyone provide step by step directions?

bojanz’s picture

I'm not sure what you're expecting from this functionality, but that expection is probably wrong.
This is an API allowing custom handlers to add form elements to a View. Then Views automatically builds the form around that.
Modules using this API are VBO (7.x-3.x), Draggable Views (7.x-2.x), Editablefields (7.x-1.x), Drupal Commerce, Commerce Add To Cart Extras, etc....
So you're either adding a field provided by one of those modules to your view, or writing your own handler. There is no "enabling" it from the UI.

Abbass’s picture

Category: task » support

@ Bojanz, Downloaded your example file from #19, but I am having a hardtime implementing it. Could you please make a video tutorial with a multistep form example, where one would select a view table's row output and continue with it to do something.

Say for example one gets a table output where the first column is made of radio select elements created with VBO. One would select a radio and that would mean the whole row is selected. Now the form will have a Next button and when clicked the row is treated. for example if the table lists contents by date created, the next button allows us to enter an email where the selected content is sent to us after submission.

You can choose another example if you want, but a video tutorial would help a lot!

Thanks

Status: Needs review » Needs work

The last submitted patch, form_id_with_args-769322-26-p0.patch, failed testing.

mstrelan’s picture

Yeah Bojanz why have you not done this already gosh! Seriously though, @Abbass, I spoke briefly about this in my talk at Drupal Down Under this year. Video is available at http://2012.drupaldownunder.org/session/views-api-exposed and you can skip to about 31:40.

EDIT: Sorry, didn't read the comment properly, I see you're asking about multi-step forms, and my video has nothing to do with multi-step.

bojanz’s picture

I plan to improve that example soon. However, it is still your best bet, along with the latest VBO 7.x-3.x-dev.
Basically, the current form step is stored in form state or ($form_state['storage'] in D6), and points to the function that gets called.
The first step is called "views_form_views_form".

So a submit handler can have:

// Advance to the confirmation form.
  if ($form_state['storage']['step'] == 'views_form_views_form') {
    $form_state['storage']['step'] = 'views_form_example_confirmation_form';
  }

which changes the step to views_form_example_confirmation_form(), which means that:

/**
 * Confirmation step of the views multistep form.
 */
function views_form_example_confirmation_form($form, $form_state, $view, $output) {
  $form = confirm_form($form,
    t('Are you sure you want to give your name to total strangers?'),
    array('path' => $_GET['q'], 'query' => $view->get_exposed_input())
  );

  return $form;
}

gets called.

Other than the example module and latest VBO, you can also take a look at the Views Send D7 port: http://drupal.org/sandbox/hansfn/1408756

I don't have time to record video tutorials right now, sorry.

Abbass’s picture

Version: 6.x-3.x-dev » 7.x-3.3

Thanks guys for your answers. I finally went with Views bulk Operations and created an action module where my user selects a row from the views and have it sent by email. I am now able to do that, however I am not currently able to print my selected row's information within my sent email $body variable!

Basically, currently I have a view that outputs a table with content title, the date published and a link to that content.
I want to select that content and use VBO actions, to send an email to the user who have published the content, and print a the very least the content title and the link to the content into my email's body.

I tried using drupal_mail and hook_mail to do that, however I am not able to print in my email those fields, specially in hook_mail in the field:

TO: I would like to dynamically select the email of the user who have published the content from his profile.

From: to select the email of the user who wants to send the email.

$body: to print the content in question's title and the link to that content all of them already selected through my views row.

Any ideas friends?...

Thank you for having answered once again it was really helpful!

here is my VBO action's code that i have found and twicked:

<?php
// $Id:$

/**
* @file
* Emails selected objects to a recipient as a list
*/
/**
* Implementation of hook_perm().
*/
function ENAS_perm() {
  return array('access email_nodes_action', 'create email_nodes_action', 'administer email_nodes_action');
}
/**
* Display help and module information
* @param path which path of the site we are  displaying help
* @param arg array that holds the current path as would be returned from arg() function
* @return help text for the path
*/
function ENAS_help($path, $arg) {
  $output = '';  //declare your output variable
  switch ($path) {
    case "admin/help#ENAS":
      $output = '<p>'.  t("Sends an email to given recipient listing all the stockists selected in the view") .'</p>';
      break;
  }
  return $output;
}
/**
* Implementation of hook_action_info().
*/
function ENAS_action_info() {
  return array(
    'ENAS' => array(
      'label' => t('Email list of nodes to a recipient'),
      'type' => 'node',      // this should probably be changed to something else!
      'aggregate' => TRUE,       // tell Drupal this action operates on all nodes at once (not one by one)
	  'pass rows' => TRUE,
      'configurable' => TRUE,    // tell Drupal this action requires form input
      'hooks' => array(),
    ),
  );
}

/**
* Implementation of a Drupal action.
* Passes selected nodes as arguments to a view.
* @param $objects array of node IDs
* @param $context array of other parameters
*/
function ENAS(
  $objects,
  $context = array()
) {
  global $user;
 
  // $objects is an array of object IDs, since the action includes aggregate.
 
  /**
   * @todo Build the email containing the node descriptions here.
   * We need to loop through getting the nodes from the $objects ID array and
   * building the body of the email into $params['context']['body'] and subject into $params['context']['subject'] 
   */
   
  $recipient = $context['recipient']; 
  $account   = $user;
  $language  = user_preferred_language($account);
  $params    = array('account' => $account, 'context' => $context);
 

  if (drupal_mail('ENAS', 'action_send_email', $recipient, $language, $params)) {
    watchdog('action', 'Sent email to %recipient', array('%recipient' => $recipient));
  }
  else {
    watchdog('error', 'Unable to send email to %recipient', array('%recipient' => $recipient));
  }
   
}
/**
* Implementation of hook_mail().
*/
function ENAS_mail(
  $key,
  &$message,
  $params
) {
  $account = $params['account'];
  $context = $params['context'];
 
  $variables = array(
    '%site_name' => variable_get('site_name', 'Drupal'),
    '%username'  => $account->name,
  );
  
  if (isset($params['node'])) {
    $node = $params['node'];
    $variables += array(
      '%uid' => $node->uid,
      '%node_url' => url('node/'. $node->nid, array('absolute' => TRUE)),
      '%node_type' => node_get_types('name', $node),
      '%title' => $node->title,
      '%teaser' => $node->teaser,
      '%body' => $node->body,
    );
  }
 
  $subject  = t('I would like to exchange some cash!');
  $body = strtr('I want to reply to your offer', $variables);
  $message['subject'] .= str_replace(array("\r", "\n"), '', $subject);
  $message['body'][]  = drupal_html_to_text($body);
}

function ENAS_form($context) {
  $form['recipient'] = array(
    '#title' => t('Email Recipient'),
    '#type' => 'textfield',
    '#description' => t('Enter an email address to send the list of nodes to.'),
    '#default_value' => @$context['recipient'],
    '#required' => TRUE,
  );
  return $form;
}
/**
* Validate ENAS form submissions.
*/
function ENAS_validate($form, $form_state) {
  $form_values = $form_state['values'];
  // Validate the configuration form.
  if (!valid_email_address_list($form_values['recipient'] ) ) {
    form_set_error('recipient', t('Please enter valid email addresses.'));
  }
}
/**
* Verify the syntax of the given comma-delimited list of e-mail addresses.
*
* @param $mail
*   A string containing comma-delimited list of e-mail addresses.
* @return
*   TRUE if all the addresses are in a valid format.
* @todo
*   Put this function in the correct place for user functions.
*/
function valid_email_address_list($mail) {

  $ret = true;
   
  $email_array = explode(',', $mail);
 
  foreach ( $email_array as $key => $email_address ){

      if ( !valid_email_address( $email_address ) ){
         $ret = false;
          break;
     }
 
  }
  return $ret;
}
function ENAS_submit($form, $form_state) {
  return array('recipient' => $form_state['values']['recipient']);
}

dawehner’s picture

A better place to ask is probably the issue queue of views bulk operations ...

dawehner’s picture

Status: Needs work » Fixed

Update status.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hbgy1s’s picture

thanks :)

rafamd’s picture

Version: 7.x-3.3 » 6.x-3.x-dev
Category: support » task

restoring category and version

Abbass’s picture

I don't know why you re-opened this issue exactly, but like Bojanz suggested it somewhere you can basically user VBO+ rules actions or rules components to do almost anything....here is a free screencast by nodeone that can help you understand how to use them....VBO+ Rules

Hope that helps, otherwise please clarify your request.

diqidoq’s picture

Issue summary: View changes

... otherwise please clarify your request.

The headline and description of the issue promotes something else than that what is discussed here further. As replicable on several other comments in the issue queue above, the reader assumes that this makes the option available in views to create forms in views the default "views way". Any idea to change the title, even if it is a lil bit late? But there are already issues on Drupal StockExchange referencing to here assuming exactly this.