Views cycle, Views rotator, and Views slideshow, Oh my!

Hm. The main difference is that I had no idea views_rotator existed when we wrote views_cycle. :-( (And then the site that views_cycle was for was delayed in launching, so we couldn't release the module until recently.) Mayhaps we should compare notes.

+1

There is a very useful comparison of rotator / slider modules.

Yeah, I think this is fixed now since, afaik, crell and mfer are coordinating now.

Well, as I'm implementing a Views rotator/cycler thing for a client site currently, I'm finding myself patching Views Cycle (chose it because of its tab option) in order to make it more flexible. There's probably not much point in my continuing to submit the patches to the issue queue here so maybe I should get more involved in the co-ordination effort. Thoughts, mfer, crell? Who's taking the lead on this?

I haven't looked at views_rotator yet, so I'm not sure how they compare. Views cycle's two "cool features", IMO, are the thumbnail support and the hook-based support for different CSS skins. Whether it makes sense to put that into views_rotator or fold views_rotator's cool bits into views_cycle I don't know yet. mfer, what are views_rotator's cool bits? :-)

And of course there's also views_slideshow which at some point quietly started using jquery.cycle as well, from what I understand. We should look Aaron in as well.

I did screenshots of the config options of Rotator, Cycle and Slideshow when I was doing the module comparison doc - see attached. This gives a good idea of what options each offers...

i personally want to strip out the display functionality from views slideshow, and have it serve as an API for slideshows, by encapsulating the views functionality.

i've already begun the process (with the dev version of the module), and the API works quite nicely for http://drupal.org/project/views_slideshow_imageflow.

i'd started some work some time ago to get the module working with jcarousel, then ditched that in favor of cycle. however, i think the idea of using it as an API would be superior, and would allow all the modules to be lighter and easier to maintain.

how does this sound? if you're interested, i can work on a patch (and extend the API if needed) to start integration.

That sounds awesome - I had been thinking it would be great to abstract out the 'choosing your content' side of things (i.e. the Views style plugin part) from the 'awesome jQuery display' side of things (i.e. picking which jQuery plugin you want). Is that what you mean? Like could you then use, say, accordion instead of cycle? Obviously there's different mark-up required for the different plugins though and the config options would be different so I'm not sure how that would work, but it sounds like the right direction for all this stuff.

Reopening for discussion...

I'm not sure I understand how an API would work. Taking the example of views_cycle, there's really nothing in it that is not tied to the cycle plugin in particular that isn't just Views itself. The configuration for jquery.cycle is very different than it would be for imageflow, as would the HTML. What would be the genericized part?

I am thinking of releasing the ddblock module as a views_slideshow plugin like the views_slideshow imageflow module.

This way users can use all the settings the ddblock module already provides (see attachment of settings) for the cycle plugin as a views plugin and also the themes provided by ddblock module can be used (see examples of free themes and commercial themes).

If you have more questions about the ddblock module, feel free to ask.
I am curious what you think about releasing the views_slideshow_ddblock module.

ppblaauw: as a huge fan of ddblock i'm totally for your idea of making it work as a views plugin!

@mfer

Thanks for your reaction!!!

You know the dynamic display block module.
It also is a wrapper module for the jQuery cycle plugin.

merge all cycle plugin wrapper modules
Why not merge all the modules which support the cycle plugin into one module to support the cycle plugin for views?
Views_slideshow
Views_rotator
Views_cycle
Views_ddblock

develop API
I think the way Aaron is going with the views_slideshow module to develop an API for dynamic display modules using Jquery plugins or other plugins to display static data in a dynamic way, is the way to go.

This module could be named Views Dynamic Display Kit (views_ddk), Views Dynamic Display Technology (views_ddt) or another good name, which is an API for the different plugins.

Even using views different plugins would use different content. e.g the views_slideshow imageflow module only needs an image, other plugins need text for slides, read more buttons, pager items, etc.

plugins
These plugins could be:
One or more slideshow plugins (cycle, slideview, galleria)
One or more carousel plugins (jcarousel, multimedia portfolio, etc)
One or more scrolling plugins ()
etc.

Naming for the plugins could be:
[api]_[functionality]_[plugin]
views_ddk_slideshow_cycle
views_ddk_slideshow_slideview
views_ddk_carousel_jcarousel
views_ddk_carousel_multimedia_portfolio

But better suggestion of course welcome.

API for content not using views
Also for non views content I would propose a Dynamic display Kit which provides an API for the different plugins.

The difference here is that the content gathering is different and usage is different.
The usage with views is filtering content you want to show in the dynamic display plugin.

Usage for the Dynamic display kit is more for dynamic data which does not change often and you don't want to you use views.

Like a banner slideshow on an Internet site where 3 slides are sliding in the header.

Content can come from:
A folder in the directory
One node
One nodetype
One Imagefield
etc.

This ddk would have plugins for input and plugins for output.

API advantages
By providing an API for the plugins, not all plugins have to handle the content gathering side of the functionality and can be easier to build, less code, less errors, etc.

There are a lot of jquery plugins developed with more and more functionality. Jquery plugins for the different functionality come and go. E.g the jQuery Jcarousel plugin is not maintained/improved the last year I think and there are better Carousel plugins available now.

Look at e.g at http://www.iterasi.net/openviewer.aspx?sqrlitid=8hn0k0pgtkwafrrtvy9y_a for a list relatively new jQuery plugins. There are a lot more!!!

If developing a wrapper module for jQuery plugins is relatively simple, Drupal could provide support for the best (stable) functionality solutions.

Also the plugins could be more organized when using an API or maybe API's.

Theming dynamic display plugins
Another action point would be to focus on the theming side of the plugins.
Same as with Drupal.
The functionality of Drupal is fantastic but if there are no contributed and commercial themes for Drupal it will not be used much.
To make plugins successful there should be a theming layer for them to easily add contributed and commercial themes.

Dynamic display technology framework
I would be pleased working together on this.
(The ddblock module is going this way already, will work on it as much as I can, but what I hope is: that we can work together to get a dynamic display technology framework in place.)

Maybe good to publish this or a more detailed proposal on one of the groups.drupal.org places.
(maybe the group module proposals is a good one or make a new group Dynamic display technology.)

Hopefully others will also react. (Will wait for more reaction first before publishing it somewhere else.)

Greetings,

Philip Blaauw

I'll be honest, I still don't understand how a "generic API style plugin for jquery plugins" would work, since each jquery has its own API anyway. The common parts of such an API are... well, Views style plugins themselves.

I'd love to see all of the cycle plugins merged, which is what mfer and I are doing with cycle and rotator. (We decided to merge into views_cycle mostly for the namespace, which is more descriptive.) I cannot speak for other module maintainers, though, as to what their plans are.

watching

Fantastic! I'm so glad to hear that you guys are collaborating to merge these together :)

The big reason I wanted to use Views Cycle was for the tabs. I was using Views Slideshow, but it didn't have this feature. Would it's functionality also be eclipsed by the merged module? I'd absolutely love to see that comparison page disappear into history :D

For future merged module: how about using LibraryAPI to simplify installation of the jq library?

Merging all the slideshow modules to build one ultimate powerful slideshow module would be awesome! There's too much confusion in which one to pick and they are all nice, but not very customizable.

subscribe

subscribe

subscribing

subscribing this looks exciting :) lol

Subscribing.

Here's the issue in the views_slideshow queue so we can work out the best way forward for realising aaron's masterplan:

http://drupal.org/node/757190

Here are my thoughts on how users and developers can benefit from an api.

1) The api can deal with connecting with views. This would be hook_views_api, extending the views_plugin_style_list, prepping the options form. Although not a big deal it's one less thing to worry about.
2) Provide a method to add a rotator choice. Cycle, Imageflow, Menu cycle
3) Provide a method to add a pager choice. Numeric, Thumbnail, Slider, Carousel, Field
4) Users would only have to choose one style in views for rotating through a view. Making it simpler to switch between different types of rotation methods.

There may be more that I'm not thinking of. In views_slideshow I am trying to continue Aaron's work of trying to create an api for modules to hook into. Hopefully when 2.0 is released we'll have a good base to grow on, but I'm interested in hearing any other ideas on how this can be handled.

Anybody know any way to do this kind of thing in D7 or what the upgrade plan is for D7?

2) Provide a method to add a rotator choice. Cycle, Imageflow, Menu cycle

By this do you mean the ability to use any slideshow script e.g. Coda Slider instead of jQuery cycle?

Sure the api shouldn't provide the jquery, or whatever js, plugin. That's up to the modules that use the api module. In D7 this is even more the case with the plugin manager.

Awesome, just checking we're on the same page :)

I still don't get it. jquery.cycle has an entirely different set of API options than other jquery visual plugins. How do you merge those into a single views plugin?

So here is how views slideshow handles it.

1) You register your module with the api. It's a simple hook that returns an array 'module_short_name' => 'Module Long Name'
2) It provides a way for you to pass on form elements to the api to display in the style plugin settings form.
3) In the theme.inc of the sub module it does a preprocess that merges the settings values with the defaults and then adds it to the js settings. You can see the partial method below. Haven't looked into it but this could possibly be handled by the api automagically.

function template_preprocess_views_slideshow_singleframe(&$vars) {
  $options = $vars['options'];
  $id = $vars['id'];
  $rows = $vars['rows'];
  $view = $vars['view'];

  $settings = array_merge(
    array(
      'num_divs' => sizeof($vars['rows']),
      'id_prefix' => '#views_slideshow_singleframe_main_',
      'div_prefix' => '#views_slideshow_singleframe_div_',
      'id' => $vars['id'],
    ),
    $options['singleframe']
  );
  drupal_add_js(array('viewsSlideshowSingleFrame' => array('#views_slideshow_singleframe_main_'. $vars['id'] => $settings)), 'setting');

4) There is a separate js file than the plugin that is loaded that processes those settings above and sets the correct options for cycle and then loads cycle on the page.

Hope this makes sense.

Watching...

subscribe

sub

What is the latest status on this group effort?

Nothing has been happening from the views slideshow end. Right now I think we have too many different settings and philosophies on how this can be accomplished. This is just what I gleaned from small conversations not that we have sat down and discussed it in any detail.

That's understandable!

What is your prefered module and method?

Since I maintain Views Slideshow I'm sure I have a bias. :)

subscribe

Subscribing. Thanks

As per the project pages, the views cycle and views rotator maintainers have decided to deprecate their modules in favor of views_slideshow. So I guess that resolves this issue. :-)

Now on to the 30 other such modules in contrib...

For people who are looking for slideshow modules in Drupal7,
You can use https://drupal.org/project/views_stylizer through which you can apply any jquery slideshow plugin to your view.
Video demo: http://www.youtube.com/watch?v=nJREhEcuddQ

Cycle plugin: http://drupalsauce.technikh.com/add-on/jquery-cycle
tCycle plugin: http://drupalsauce.technikh.com/add-on/jquery-tcycle