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!
Comment | File | Size | Author |
---|---|---|---|
#19 | rules_508550.patch | 4.36 KB | Steven Jones |
#18 | rules_508550.patch | 4.4 KB | Steven Jones |
#4 | views.rules_.inc_.diff | 2.41 KB | aantonop |
#3 | views.rules_.inc_.diff | 2.34 KB | aantonop |
views.rules_.inc_.diff | 2.29 KB | aantonop |
Comments
Comment #1
dawehnercool stuff :)
This will not work. :)
Additional it would be cool to allow arguments. I don't know wether this is hard to implement
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedViews 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).
Comment #3
aantonop CreditAttribution: aantonop commentedOk, 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:
Comment #4
aantonop CreditAttribution: aantonop commentedTurns 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...
Comment #5
fagoLet'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.
Comment #6
aantonop CreditAttribution: aantonop commentedfago,
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?
Comment #7
fagoCool, 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!
Comment #8
mansspams CreditAttribution: mansspams commentedI'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.
Comment #9
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #10
BenK CreditAttribution: BenK commentedSubscribing....
Comment #11
NikLP CreditAttribution: NikLP commentedBusdriving
Comment #12
webwriter CreditAttribution: webwriter commentedSubscribe
Comment #13
servantleader CreditAttribution: servantleader commented+1
Subscribe
Comment #14
YK85 CreditAttribution: YK85 commented+1 subscribing
Comment #15
that0n3guy CreditAttribution: that0n3guy commentedsub...
Comment #16
Steven Jones CreditAttribution: Steven Jones commentedTotally subscribing, will test and provide feedback as soon as I can.
Comment #17
Steven Jones CreditAttribution: Steven Jones commentedI'm not sure we need a AJAH form to select a view display, standard practise is to just use a optgroup select list to choose both at the same time.
I'll get a patch up and working asap.
Comment #18
Steven Jones CreditAttribution: Steven Jones commentedHere's a patch that includes selecting a view using a select box, and passes in the arguments correctly, they are optional too.
I'm still not sure how you'd use the view in other, later conditions, as the view result is only around in a string variable, and needs to be available to token really. @fago is there an easy way to get the rendered view into the token system so it's rendered output can be used almost anywhere?
Comment #19
Steven Jones CreditAttribution: Steven Jones commentedThere is, of course, a bug in the above patch, so the view would never get rendered. The attached is tested and works!
Comment #20
Steven Jones CreditAttribution: Steven Jones commentedNeed others to test this patch, you may want to patch rules with #723980: Expose basic rule variables to token so that it's super easy to see the output of the rendered view.
Comment #21
fagoThe patch in #19 looks fine to me! I just committed the mentioned token related patch.
@code:
Well as it's code to to provide an action for views it should go into the views module - don't know though whether merlin is open for that. Anyway, maybe it would ease maintaining / improving it nevertheless, if it would go into a separate "views-rules" module? Rules itself currently doesn't ship with any rules integration for a contrib module and I'd like to keep it that way.
Comment #22
Steven Jones CreditAttribution: Steven Jones commentedGiven that this issue started in the views queue and moved into the rules one, we're probably not going to get it in either, which is a shame.
Moved to a new module for work to be able to continue.
Comment #23
YK85 CreditAttribution: YK85 commentedyea, all contrib modules with views integration has a folder within named 'views' and a modulename.views.inc file.
I believe this is the same methodology of Rules modules, where other contrib modules wanting to integrate with Rules will have the rules.inc file within its module folder, and not in the Rules module.
I have not seen the contrib module views inc files included with the Views module (i think it will be difficult for the Views maintainers to maintain all the different contrib modules).
Is there a chance of this views integration living within the Rules module folder as a rules.view.inc file?
Or is the best path to take to have it as a separate module?
Comment #24
fagoWell the point is this is not like any regular views integration - I'm not sure whether merlin has realized that in #2. Instead it's a rules action for views, thus code that integrates views with the rules module and not the other way round.
So if you prefer to have that shipping with views, I'd suggest you'd give it another try.
Comment #25
Itangalo CreditAttribution: Itangalo commentedSubscribing
Comment #26
2ndmile CreditAttribution: 2ndmile commentedsubscribing
Comment #27
mitchell CreditAttribution: mitchell commented#521640: sql query in/as condition references this issue in regard to using views results as conditions.
Comment #28
keesee CreditAttribution: keesee commentedSbcr
Comment #29
Azol CreditAttribution: Azol commentedsubscribing
Comment #30
joelstein CreditAttribution: joelstein commentedsub
Comment #31
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #32
Cyberwolf CreditAttribution: Cyberwolf commentedWould be nice to have a rules condition based on views, that allows for comparison of a number with the count of the views result (>, >=, <, <=, =).
An example: if count of a certain node type with the same values in one or more specific fields (arguments of the view), then "set a form error" (with Rules forms module)
I am willing to contribute such features to this project, let me know if you are interested in including it.
Comment #33
NikLP CreditAttribution: NikLP commentedYou can achieve the result mentioned in #32 using programmatic calling of views in the php condition widget.
Edit: I think.... I've achieved a "show me all the nodes of type x" from views and used the count to evaluate a true/false, and return that...
Comment #34
Cyberwolf CreditAttribution: Cyberwolf commentedI know that is possible. You can accomplish about everything with the PHP condition widget, but it's not very easy to reuse, feels rather like a hack and is not supposed to be used by non-programmers.
Comment #35
modctek CreditAttribution: modctek commentedWatching this with much interest +1
Comment #36
Steven Jones CreditAttribution: Steven Jones commentedThis has been committed in http://drupal.org/cvs?commit=364506.
Will open another issue for the condition.