The product data to the right (or bottom on mobile devices) imitates the product detail page commonly used in the majority of shopping cart systems. The functioning part is the product variation switch or color swatch, here labeled as "color variant". The example only aims to show a more or less clean implementation of how the zoom on hover AJAX-ZOOM extension looks in place of a different one and how you can connect it to color- or product variants in general.
"position": "inside" // or "right", ...
"axZmMode": true // or false
"maxZoomMode": true // or false
"galleryDivID": "az_mouseOverZoomGallery" // or false
If it is, e.g., a "Smarty" template for the frontend and the correct paths to high-resolution source images are not available in template variables, you should check the documentation of your system and find a hook where you can define those variables. You may also need to find internal class methods that return the required information about source images or request it via a database query on your own. Generally, there is not just one possibility to receive the correct information. It depends on the system where you want to integrate the new viewer.
That is a more complicated task because, in contrast to plain images, you need to let the administrators upload the 360 spin images somehow.
For normal images, systems already have it at the backend.
Things get even more complicated if your client wants to have 360 views for product variations.
If due to high expenditure writing a backend module that provides this functionality is not an option,
this is what you can do: create a top folder for 360 product images, e.g.,
Now, every product within a system has an ID, SKU, UPC or a different identifier.
You should carefully look at them, understand the structure thoroughly, check with the available data
and finally find the logic that you can use to convert those identifiers into a path.
/360views/123/222 can be a path for a product variant with the main ID 123 and variant id 222.
In a different system, there could be no "main ID" but only variant IDs.
Howsoever it turns out;
the goal is to find a structure that you can communicate to the customer or
the 360 product photographer so that they can create these paths, e.g., using FTP and upload the 360 product spin images in there.
Once this workflow establishes, as a programmer, you only need to check with server-side code if an assumed folder exists and is not empty.
Then, forward this information and data to the viewer.
At least for customer presentation, testing, and proof of concept the above procedure is quick to implement.
Later on, you can still provide a backend functionality for that.