Best practice for storing uploaded images
In my XPages app, users can upload images. At this point, each image is thumbnailable, and the thumb is then saved as an attachment in a single NotesDocument. In the browser, thumbs point to the Notes attachment URL "[UNID] / $ FILE / [ATTACHMENTNAME]".
It seems to me that a bit of "overkill" has 1 document per image, and I believe it will also have a performance impact when many image documents are in the same database, such as when creating view indexes for views linked to other documents. Hence, I want to ask if there is a better way to store images if you just want to show them in the frontend / browser and don't need to store additional information about them.
I would like to save my thumb files directly to a folder on the filesystem and then make that folder accessible via http (s). However, I don't know how to do it. I also thought about saving thumbs in the WebContent folder, but I am not aware of the disadvantages of using this approach either. Does anyone have experience with this or can provide another solution for my problem?
source to share
I don't think you will be able to save them in the NSF WebContent folder, and it would not be a good idea. This will keep the images in the design, but the images must be data.
You can save them in a folder under \ domino \ html, but again, this is not recommended. If you want to cluster, the files will only be on one server; they will not have any security, so everyone can access them; if there is any corruption, you will have to rebuild; their preservation may require higher access rights; the administrator may not want to give you view access, so maintenance will be more difficult.
My recommended solution would be to store them in a database. It can be replicated and Domino can handle it accordingly. Plus, you have all the necessary security settings. If DAOS is enabled on the database / server, they will not affect the physical size of the database.
The key is whether they only download images or images + metadata or other data. For example. if it's a Person document and they are loading a profile picture. If so, I would store the image in the Person document. Since the image cannot be indexed for views, it does not affect view indexes, so the problem goes away.
If they need to be stored in the document by themselves and you don't want it to be in the same database as other data, create a separate database and save it there. If you store it in a separate database or filesystem, you need to keep the relationship between the two, so there is no reason to use this approach. Also, you can still have the same security, use DAOS, etc.
Plus, you'll probably find a lot more support on how to do it, how to fix it, etc., because very few applications or developers are likely to take the file system storage approach where Domino is designed for and has a long history of storing attachments in documents (for example, the document library template that has been around since I started with Domino 15 years ago).
source to share
I created a framework for this. In the case of photos, when uploading a JPG, I take the image and resize it 2 times. I keep the original "Large" and "Small" versions. So I am actually creating 3 databases ... Original, Large and Small ... Although it may seem overkill ... it is actually quite clean and I created Java classes to deal with all 3 sizes as one. This way you delete the image ... they are all deleted. I would highly recommend 1 attachment per document.
I have not yet received a video explaining this. But my early solution, which should work, can be found here if you'd like to delve into it. https://bitbucket.org/leedy/filevault
source to share
If you upload an image using CKEditor, the images are stored in the mime object and you can actually save the images in multiple versions inside the mime object as different attachments with a different name for later reference. I don't have any code ready, but it should be possible.
source to share