Make VBO work with different Views styles

There's isn't currently a way to support arbitrary display styles. This would require significant changes in VBO core, so unless there's lots of demand for it, or someone is willing to help out with the implementation, I won't have the ability to work on it soon.

+1

I'm trying to reuse VBO for end-user purposes, ie building views that let users do operations on nodes and users (eg sending mail to other users in a view). BTW, do you think this might be a bad idea? Most use-cases seem to be for administrative purposes.

Anyhow, we would like to keep the frontend of our site free from tables - so choosing another layout such as Unformatted would be nice. I just peeked into the code and noticed this...

// Render the view as table. Function from views/theme/theme.inc
template_preprocess_views_view_table($vars);

... in theme_views_node_selector(). Do you think there are many other dependencies in the VBO code if we want to change the style by calling template_preprocess_views_view_unformatted()?

Thanks,
Claes

@Claes:

> BTW, do you think this might be a bad idea?
The VBO permission system should allow to safely expose this functionality to end-users. The actions_permissions module helps ensure that no unwanted actions are exposed to unprivileged users. In fact, I think VBO is already being used with end-users in some cases.

> Do you think there are many other dependencies in the VBO code if we want to change the style by calling template_preprocess_views_view_unformatted()?
Significantly, the plugin style class views_bulk_operations_plugin_style extends views_plugin_style_table. So changing the style will require extending the class of the desired style.

Alternatively, you might want to consider another approach to implementing class views_bulk_operations_plugin_style: extend the base views_plugin_styleclass and use the Composite pattern to instantiate the desired base plugin inside the new class, forwarding calls to it when necessary. This would even allow for VBO admins to choose which style should be extended for VBO.

In any case, please keep me informed of your progress and I'd be glad to help.

Ok, thanks for the feedback! We will probably have to stick with tables for the time being, I have too little time to work with this right now - a little baby here at home doesn't appreciate me coding PHP during the days ;-) This might change in the future though, and I'll let you know if I decide to give this a try.

I think better approach is to implement own theming functions/templates for every style supported. We could modify theme registry dynamically when a View is "VBO enabled" so our function/template would be used first. I think it's better than implement style-wrapper both in terms of simplicity/amount of code and compatibility: any code that checks current View style would not notice any difference because style would be the same.

@crea: can you explain you idea more fully please? For example, let's say we want to convert the current table style with your approach. How would we approach this?

Well in theme function/template we have themed rows. We could prepare a form array, and insert themed rows inside, adding checkboxes in the process. Then we could pass it to drupal_render() and in the end we would have a VBO form. If deeper modification was needed, we could also perform same operation with individual fields in a row.

For example, let's say we want to convert the current table style with your approach. How would we approach this?

We would implement theme function/template following default Views template (views-view-table.tpl.php) pattern. We would then process rows in that function/template, and drupal_render() it together with our checkboxes. Then we would need to somehow provide Views UI checkbox "Enable VBO for this View" that would invoke theme registry rebuilding enforcing the use of our theme function/template.

Feel free to correct me cause I don't have deep knowledge of VBO, that is only my expectation of it's work.

Thanks crea. This clarified a little bit what's needed. Here's what I am currently thinking:

Currently, the VBO plugin style is rendered by calling drupal_get_form on the VBO form function. This function builds a form that contains the various VBO elements (operations drop-down, execute button) including a custom element of type "views_node_selector" that is defined in the module. That's the element that renders a table with checkboxes.

To make this generic to any plugin style, the following changes would need to be made:
* Alter plugin style settings forms to add a checkbox "Make VBO"
* Alter the theme function of existing plugin styles to redirect to a new VBO function
* This function would call drupal_get_form on our form function, passing a reference to the original plugin object to the "views_node_selector" element
* The "views_node_selector" element would lookup a template / preprocessor pair that corresponds to the original plugin, but with the checkboxes weaved in

If anyone's interested in taking a stab at implementing this, I'd be very grateful :-)

I'm going to put my +1 in for wanting this but am not any help with making it happen, I'm afraid. :( I'm planning on making a forum moderation submodule for AF that will make use of VBO and being able to use it with my existing Views styles would be really helpful. Hopefully someone out there has the itch and the means to scratch it. :)

Michelle

subscribe

. (sub)

I was also struggling to theme the rows in a table generated by vbo.
I first had a normal view and themed the row style with a tpl function, then my view turned into a vbo and none of this was working... I would really love to see a views_view_bulk__myview.tpl file !
When looking for overriding theme functions I came across this documentation: http://drupal.org/node/173880

I quote:
"Converting a theme function into a template takes some initial work but once it is done, it's easier to work with. If you are collaborating with a designer, the conversion will enable them to focus on designing, not coding. There are many templates already available in core and many more will be converted in future versions. Contributed modules that follow best practices should also have templates available."

Is there anyone who could make this change from a theme function to a theme hook with associated tpl file? I don't have the time to do this...

interesting topic!

sub

Bumping this up again to put out a plea for someone, whether maintainers or just a coder wandering by, to make this happen. The #1 reason people give for not using Drupal's forums is that moderation sucks. If I could integrate VBO into Advanced Forum, I believe we could get past this. But I'm simply swamped with everything I'm already doing and just can't dive into VBO's internals. There has to be someone out there who has the ability to do this and a bit of time. Don't do it for me... Do it for Drupal's forums. :)

Michelle

Need this too!

Well, I need this for a client, let see if I can make it happen.

@tim looking forward to your contribution! Let me know if I can help.

Yay Tim!

Michelle

infojunkie, your suggestions in #12 make the most sense to me, and that's how I planned on going about this.

However, I hit a big roadblock early. Unless I'm mistaken, there is no way to alter the style options of another plugin without re-implementing the entire plugin. I don't think hook_views_plugins_alter() can do it. The closest it gets is the boolean $plugins['style'][$plugin]['uses options']. That means we'd have to have multiple plugins, e.g.

class views_bulk_operations_plugin_style_table extends views_plugin_style_table {...}
class views_bulk_operations_plugin_grid extends views_plugin_style_grid {...}

Re #24: It makes sense that we would have to extend each style plugin explicitly. Not only to add our VBO-specific option(s), but also to supply a new theme template that contains the checkboxes. But that's not necessarily a bad thing:

We need to focus on *decoupling* the VBO logic from the style plugin. In other words, it should be dead simple to create a new style plugin that is VBO-enabled because most of the VBO logic is outside the plugin.

The design of VBO today is almost decoupled. The operation-discovery mechanism should be moved out of the current VBO style plugin, and the "views_node_selector" FAPI element should be redesigned to accept an arbitrary template (instead of the hard-coded table logic).

Hope this makes sense to you :-)

Makes perfect sense. I'll be back working on this tomorrow, and I'll post updates. Are you ever on IRC at all? Just in case I have some quick questions :) I'm usually in #drupal as timplunkett.

I guess the question I should ask is, which branch of VBO should I be working on? I'm a little confused by the death of vbo-6.x-3.x, and I personally need this to work with views2.

You should be working on VBO 6.x-1.x-dev. The 3.x branch died because I merged the differences back into 1.x.

You can find me on #drupal as infojunkie.

subscribe

subscribe

subscribe

sub

I'm really dropping the ball here. Though I'm still trying to work on this.

Thought I'd point out some related development going on over here: #825100: Allow template_preprocess_views_view_table() function override

The patch I've added should allow you to override the default table output of VBO, hopefully we can use that approach to expand to other views styles as well... :)

Hello, please take a look at this patch I've sent to commerce module queue.

This may provide some insight on how to make VBO module better, by allowing you to chose which style plugin to use to render the view.

sub

I'm wondering if it would be possible to do this by creating a global views vbo field handler that could only be added once to a display. That way the select elements would be rendered as a field and could theoretically appear anywhere.

#681468: Create pluggable display extenders should make this possible.

@dkinzer: it's not just the checkboxes, it's also the whole multi-step form.

@tim.plunkett: actually, we would need a *style* extender, not a display extender. But that's an interesting approach worth more thought.

Repeating what I said in #1108578: Drupal 7 status (VBO):
For anyone interested, I'm doing some VBO work at this sandbox: http://drupal.org/sandbox/bojanz/1149374
It branches off from today's 7.x-3.x and makes VBO a field, allowing it to be used with any style plugin.
This actually works!

This will be the way forward for D6 as well - when the required infrastructure pieces are present for D6.

subscribe

I just wanted to say that Views 6.x-3.x now also has Views Form (the idea that recidive started and mentioned in #34), so it's possible for a D6 branch of VBO to make it happen (though at the expense of dropping Views 2 support).
This is working nicely in VBO 7.x-3.x, so it's just a matter of porting it over.

Of course, it's still a significant time investment so if someone wants to see this happen, jump in!

subscribe

This is great news, @bojanz, looking forward to use it on a project in the near future. Thanks!

Closing the issue for now. It probably won't get any attention from the maintainers (infojunkie and me). Too late in the D6 cycle for that to make sense.
If someone wants to port this from 7.x, I'm guessing the 6.x-3.x branch can be revived to house it.

Maybe it's better to move this back to 7.x-1.x-dev and mark this fixed instead of won't fix?

People may come to this issue and think this is not implemented in 7 yet.

Okay, sure.

sub

6.x

@mindaugasd: This issue is "won't fix" for 6.x so not any point in subscribing...

Michelle