Integration with Views module
| Project: | Rules |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | aantonop |
| Status: | needs work |
| Issue tags: | rules integration |
Here's the beginning of an integration stub for the rules module.
For now, this provides just one action that can be invoked in a rule (see rules module).
The action takes a view name and display ID and renders (embeds) that display output in a text variable. Subsequent rule actions can use this text variable. One common use is to invoke a rule that emails the contents of a view to a person. For example, let's say you want to send a weekly update "dashboard" to certain people by email. You can create view, with HTML and links or just plaintext listing all the nodes. You setup a rule to generate the view and then email the result in the body of an email.
The code is currently in production in my site and works without problems. It is quite simplistic and can be enhanced quite a bit.
I am still adding features to this for my use, if people find this useful I will contribute changes back. My todo:
- Enable passing arguments to the view, especially useful for filter arguments
- Present a select list with the available views and displays instead of strings. That way the user doesn't have to go looking for the view name and display ID
Please test, review and comment!
| Attachment | Size |
|---|---|
| views.rules_.inc_.diff | 2.29 KB |
#1
cool stuff :)
+/**+ * Implementation of hook_rules_action_info().
....
+function views_rules_oaction_info() {
This will not work. :)
Additional it would be cool to allow arguments. I don't know wether this is hard to implement
#2
Views only provides support for Drupal core data. Modules are expected to provide their own Views support (and many, many modules have embraced this, so it works).
#3
Ok, so now we're back to installing this under the rules module, not as a patch for views.
I fixed the vi-typo-fat-fingered-im-so-stupid error, and fixed the file location to patch rules module instead of views.
Here it is again:
#4
Turns out that supporting arguments is not hard. This works for arguments in much the same way as the preview box in views. I believe passing arguments separated by "/" works. I've only tested with a single argument and it works.
More testing and review needed...
#5
Let's ensure the code is ready, then we can see whereto it goes.
@patch: $display_id_description This is not really a description about the argument, but a help text. Use the action form callback to set this. Also the view should be selectable in a form. Isn't it possible to make the display selectable too? Then is it possible to render a view without html? Perhaps we should add an option to use http://api.drupal.org/api/function/drupal_html_to_text/6 on it.
#6
fago,
I will try and fix both of these issues.
I can pull a list of views and a list of displays and create a select form. Let me work on that. The biggest issue I have is that the select dropdown for displays depends on which view you picked. It requires a two-step form with AJAX or something to reload the second select (displays) once you pick the first select (views). I don't know how to do two-step forms (was trying to understand). So if I find the functions to call to pull the right info from views for a select box and the subset of displays in each view, can someone who knows forms help me do the two-step?
As for doing non-HTML, it's best to do this in the views module. In a view you can create any kind of output you want, using tables, grids, HTML , unformatted, whatever. You can also use templates to output different formats. You can even render JSON, XML or CSV using the views add-ons.
So I think the best way to handle the integration is to leave the decision of format (HTML, non-HTML, table, grid, whatever) to views, where it belongs. Not override it in rules, which can only lead to confusion ("it looks fine when I see it as a view, why is it changing after rules uses it!?!?!") If you're troubleshooting you want to be able to preview the view and expect rules to use the exact same format (HTML or not). I'm assuming we can use the views integration to do a LOT more than just HTML or plaintext email. Especially with JSON, XML, CSV or various other formats coming out of views. So I would really really strongly suggest we don't monkey with the output of views inside a rule. Let the user build the right view, test and preview it in views and then expect rules to just use it without doing anything unexpected to the views output like stripping HTML. Less confusion, less chance of bugs, less difficulty troubleshooting. We can make a note in the help or description that says: "if you want HTML or plaintext, use the views to output the right format, for exmaple "unformatted" or "table" or "grid" "
I'm still working on this, so let me make some more fixes and then re-submit here. Any other bugs or problems anyone?
#7
Cool, I'm looking forward to your next version. For doing multistep action forms you can have a look at rules_action_taxonomy_load_term_form() or the cck action.
@views display: agreed!
#8
I'm working on project that would require this. will help on testing. great work!
UPDATE: it does not work for me yet. So what exactly this action will produce? Rendered view? How do i insert this as variable in other actions (variable, syntax)? Also I still don't get View Arguments that is required value. How about view with no arguments or one with multiple? Should this be required? What is tipical value for this field?
How is this connected with this issue? http://drupal.org/node/329500
Overall this looks simple and promising, would like to learn more so i can contribute better.
#9
subscribing