To keep the code in ImageSpread.js from becoming too messy, there is some refactoring that I think should be done before adding support for viewing any additional filetypes. It revolves around introducing a new class to the codebase called a "FileHandler" or maybe a "FileViewer."
Instances of this class would have three important fields:
An array of filetypes (as strings) that it can handle
A function called something like "createView" which will take in the path to a file (of one of the supported types) and is responsible for creating the modal viewer of that file. (Like a plain image, or the more advanced .vtk viewer)
A function called something like "getPreview" which will take in the path to a file (again, of a supported type) and return an img element which is what the ImageSpread will display as the thumbnail.
Then CinemaComponents should have three pre-built FileHandlers which will represent the kinds of files we are already able to display. There would be:
A regular image viewer (PNG,GIF,JPG,etc.)
A VTK viewer
A PDB viewer
Then the ImageSpread component would keep a list of all of the file handlers that is has "registered." (The three handlers mentioned above will be registered by default). When the ImageSpread component builds the view for a file, it will search the list of registered handlers to see if there is one that supports the file's type. If there isn't one, it will just display some generic error ("Cannot display filetype .foo" or whatever). If there is a handler for that filetype, it will call that handler's getPreview function to get the image to display as the thumbnail. Then when the thumbnail is clicked on, it will call the handler's createView function which will create and display the view of the file.
The reason for this refactor is to prevent ImageSpread.js from becoming gigantic and unmanageable as we add support for more filetypes. It will also make it easier to add support for more filetypes in the future and even allow users of Cinema Components to create their own custom file handlers to suit their needs.
To keep the code in ImageSpread.js from becoming too messy, there is some refactoring that I think should be done before adding support for viewing any additional filetypes. It revolves around introducing a new class to the codebase called a "FileHandler" or maybe a "FileViewer."
Instances of this class would have three important fields:
Then CinemaComponents should have three pre-built FileHandlers which will represent the kinds of files we are already able to display. There would be:
Then the ImageSpread component would keep a list of all of the file handlers that is has "registered." (The three handlers mentioned above will be registered by default). When the ImageSpread component builds the view for a file, it will search the list of registered handlers to see if there is one that supports the file's type. If there isn't one, it will just display some generic error ("Cannot display filetype .foo" or whatever). If there is a handler for that filetype, it will call that handler's getPreview function to get the image to display as the thumbnail. Then when the thumbnail is clicked on, it will call the handler's createView function which will create and display the view of the file.
The reason for this refactor is to prevent ImageSpread.js from becoming gigantic and unmanageable as we add support for more filetypes. It will also make it easier to add support for more filetypes in the future and even allow users of Cinema Components to create their own custom file handlers to suit their needs.