Closed danbjoseph closed 9 years ago
The testbed for this is running at thejourneylab.com:7777, but not all of the advanced options and handling for that are integrated into the Asset Manager yet. I wanted to wait to have a conversation with your team about the best path forward. I'll resend that email.
For now, the Asset Manager should just be creating three thumbnails when you upload the PDF and streaming them on request. So, not being able to get to that thumbnail URL appears to be a bug unrelated to the other handling. Let's leave this open and I'll take a look.
On Mon, Jul 13, 2015 at 11:01 AM Dan Joseph notifications@github.com wrote:
I can't find the email where you mentioned that you were testing different ways of implementing this. I think the method you were leaning towards was to generate a single preview image (reasonably sized jpg or png) that is then reactively resized into lg/md/sm when there is an API request? Thumbnail retrieval through the API is documented in the readme on the v2 branch but while http://localhost:8888/api/asset/55a303117889df5003d27f8f/file returned the full file, http://localhost:8888/api/asset/55a303117889df5003d27f8f/thumbnail/lg logged a 404 to the terminal.
— Reply to this email directly or view it on GitHub https://github.com/AmericanRedCross/disaster-asset-manager/issues/13.
this may be an issue w my local instance?
http://localhost:8888/api/assets
have empty "thumbnail_ids" arraysplease note in the readme (any maybe in the create asset modal?) what file types are acceptable for successful thumbnail generation.
for non-map assets i think we can have the end-user access point display some default icon for any non-map assets.
if you edit an asset by re-uploading a file, does it handle regeneration of thumbnails as well?
I've resolved the buggy behavior here by moving the dynamic thumbnail generation from the testbed into this project.
The behavior here regarding different file types for now is simply that PDFs get thumbnails and other file types don't. After fetching the asset via the API, you can check for the "thumbnail" property - it will be blank for files that don't have a thumbnail, and the recommended action would be, as you say, to display some default on the front end.
Future alternatives might include generating thumbnails for more types of files and assigning a default thumbnail within the asset manager for different file types (think a Microsoft Word icon, for example.) Let's open a new issue for your preferred option.
I'll update the Readme to better describe the new behavior.
I can't find the email where you mentioned that you were testing different ways of implementing this. I think the method you were leaning towards was to generate a single preview image (reasonably sized jpg or png) that is then reactively resized into lg/md/sm when there is an API request? Thumbnail retrieval through the API is documented in the readme on the v2 branch but while
http://localhost:8888/api/asset/55a303117889df5003d27f8f/file
returned the full file,http://localhost:8888/api/asset/55a303117889df5003d27f8f/thumbnail/lg
logged a 404 to the terminal.