Enable programmed submission of DraggableViews forms and improve Rules integration [#1699682]

Use Case 1

We have a DraggableViews configured with Flags so that when a user flags a node, it shows up in a view where they can control the order of nodes for the front page of a site. The view is showing 12 rows only (without pagination). Eventually nodes will drop out from this view when new nodes are flagged. And when this happens we want to do two things:

Clean up the order structure ({draggableviews_structure} in the case of the native handler) so that thousands of records don't clutter the structure for ever.
Execute arbitrary actions on nodes that dropped out of that view (like unflagging those nodes so that {flag_content} aren't cluttered with thousands of records for ever, updating menus etc.).

How this patch solves this

The patch provides the ability to enable "Clean-up of dropout entities" on the views field handler that will invoke a certain method on the order handler object enabling it to clean up the structure. After that a Rules event is invoked with all entities that dropped out from the view.

Use Case 2

Looking at Use Case 1 above, the order structure might not ever be built if flagging of nodes is happening without anyone going in and explicitly clicking the "Save" button the the order view. This would leave the order structure ({draggableviews_structure} in the case of the native handler) completely empty. In many cases you want an explicit order set in the structure, to avoid unexpected things to happen with ordering or saving of that view.

How this patch solved this

The patch provides a Rules action that programmatically will load the view and save the order form, causing a rebuild to happen. In order to do so, a small change needed to be done to the submit handler.

The submit handler was also move to the views field handler itself where the Views form integration allows it to live. This cases a bit cleaner and more consistent code.

Comment	File	Size	Author
	draggableviews-more-rules-1.patch	10.38 KB	dixon_

Comments

Comment #1

dixon_

he/him

English

France

commented 25 July 2012 at 08:30

Clarification:

+++ b/views/draggableviews_handler_field_draggable.inc
@@ -196,4 +204,26 @@ class draggableviews_handler_field_draggable extends views_handler_field {
+    // Use 'input' instead of mapped 'values' here. This is done because if in
+    // table display we sort by header then set weights and save, we got
+    // totally wrong results ($form_state['values']['draggableviews'] mapped
+    // wrong from $form_state['input']['draggableviews'])
+    if (!$form_state['programmed']) {
+      $form_state['values']['draggableviews'] = $form_state['input']['draggableviews'];
+    }

An if statement was added for forms submitted programmatically (through drupal_form_submit()) because those submissions won't contain any 'input', effectively overwriting values built programmatically by drupal_form_submit().

Comment #2

ygerasimov commented 7 August 2012 at 08:41

Status:

Needs review

» Needs work

I really like the idea of cleanup and programmatic submission of the view by rules.

Cleanup is operation that is specific to only native handler. So we should have settings option added only under Native handler. This is achievable using handler class options_form() method. Like it is done on Field API handler.

I can see following problems with implementation of the cleanup:
- it doesn't take care about arguments passed. So if there are several orders based on different sets of arguments they will all be cleaned.
- cleanup is done on view preprocess and not on submit. So on every displaying of the view we try to remove not needed records. This is not needed that often.

Also I don't think we should have rules action for this. Or are there any use cases when we need to trigger this action in some other way?

Regarding the triggering a view. Only one thing that is missing is arguments. I believe we should have another action argument -- view arguments. And pass these arguments to the view before execution.

Regarding moving submit function to views handler submit method, we can do that even now separately if you like.