There's currently an issue on views_slideshow for ajax loading #323366: Views Slideshow: Ajax loading support that also links here.

It would be great if a module like this could be used for things other than nodes. A views plugin that basically turns an ajax views pager into images (for navigation), with the view output set to 1 would seem to work.

Would this be a possibility for the roadmap?

Comments

udig’s picture

udig commented

cerup,
Thanks for drawing my attention to this issue.

Ignoring for a second the way things are implemented beneath the hood (whether we use the views ajax pager or custom made ajax), what is the use case you had in mind which is currently not supported? you were mentioning showing other things then nodes - can you elaborate what is the specific need?

Thanks.

cerup’s picture

cerup commented

Thanks for the quick response,

The use case is being able to create a slideshows in views (similar to views slideshow) yet load each slide through ajax. This could mean creating a field views that has images + title, or images alone, etc (really endless). The important thing is to untie it from being nodes only because that's very limiting. Allowing the same functionality as views slideshow + ajax loading would be a very robust system.

The problem with views slideshow is that it loads all content on load rather than through ajax (as you know) - making pageloads slow. If you take a look at the issue #323366: Views Slideshow: Ajax loading support you can read some other cases. It's likely that having an ajax load option could become the new standard way of doing slideshows in drupal as it'll be much more efficient.

udig’s picture

udig commented

See what you mean ('fields' row style instead of 'node')
This means a major change in the way Ajax Slideshow is implemented thus it must have a very strong case.
My earlier assumption was that a node can be shaped whichever way you like (i.e. it's tpl can include any fields you choose e.g. images + title as in your example) hence anything you might do with the fields row style can probably be done with the node row style.
Am I wrong? ( I am looking for justification to invest this effort...)

cerup’s picture

cerup commented

Actually what I'm talking about is a slideshow that would maybe go on a node (not be a node) or somewhere else on the site. It's not very typical that someone wants to load a whole node into a slideshow. Typically they want parts of a node (title + image, or field + title, etc) and they put it on a node page (or block). Yes you can customize the tpl.php but that would change both the node view and the slideshow view; meaning, if you limit the view for the slideshow you're also doing so for the node view. If this was the philosophy, it would negate views having an option for field styles. The reason you have fields is to pick the pieces you want (and also can use things from multiple types - not a single node) while also avoiding doing a node_load which cuts down on the queries.

The most basic example would be a image cck field slideshow (loading through ajax). You can't do that if you're changing the tpl.php because if you limited your tpl.php file to only show the image, people couldn't see the full node when they go to it.

Does that make sense? Not sure how to explain it more.

udig’s picture

udig commented

hey cerup,

You explained your point perfectly.
It is possible to have a dedicated tpl for the node to appear differently in the slideshow context (see this issue - #734404: Personnalized content only for the slideshow). This is not straight-forward enough and probably this is something that I should improve as soon as possible.
Whether using dedicated tpl is less efficient since we use node_load is a good question. If the module was not using ajax to call one node_load at a time, then this would definitely be the case (i.e. completely inefficient). However since the ajax is bringing single record each time I am not sure at all that the views query per ajax call is faster than the node_load per ajax call (SELECT * vs. SELECT a,b). Either way I assume that the performance hit is negligible. I should admit that I did not check that and if you have some hard data that proves there is an inefficiency I'd be happy to learn more.

Another consideration is the tabbing system. To show the titles on the tabs (which are the node titles) there is a need for preliminary query that will bring the records ids and titles. I guess there is a way to achieve that when using the views ajax paging mechanism but it requires a clever mechanism (same view should run first bringing all the titles and then again using ajax paging).

To be honest, if this enhancement was straight forward I'd be happy to go there but since it means major architectural change that will not allow much more functionality than what is already available I am a bit reluctant to go there.
I'd be happy to continue the discussion though as I might be wrong.
You are welcome to inspect the way the module was built and suggest options (or even implement yourself) that covering the above idea.

Thanks.

udig’s picture

udig commented
Status: Active » Closed (works as designed)