function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jygjyg 

Need a pattern for dealing with many images and multiple sizes

My customer of mine has about 50 Products, each with at least 3 different images per product, and each images can have a different image size within 3 places on on her Force.com Site.  That means she must create 450 images, upload 450 images into Rich Text Fields or use Documents or Static Resources and enter 450 fields on Products that contain URLs to those records  

 

There must be an easier way to accomplish this.  Does anyone have a pattern?

 

thanks,

 

Jason Gabler


Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

I had built a solution once where there was a one-click upload for a file to a product; it would be uploaded as an attachment to that product. Furthermore, I had a custom field (text) that would contain the record ID of the current product image to display (which was actually displayed via a second field, a formula, for display on the product page itself, or in reports).

 

The images could, and should, be formatted by the site page by specifying a height or width. All modern browsers will happily determine the opposing metric necessary to maintain the aspect ratio. Of course, if you specify a height and width, then the browser will stretch the image to fit the bounding box. I'd advise against this, unless you're sure your client will be uploading images that are of the same ratio. You could, however, use some CSS trickery to make a bounding box that would crop the image to a precise dimension.

 

So, here's what I'd suggest. Create a CSV file that contains the following data:

 

ParentId, Body, Name, ContentType

(Product2Id),C:\PATH-TO-FOLDER\IMAGE.EXT, "Product View 1.EXT","image/legal-mime-type"

 

Once you have this CSV, about 451 lines long (header and 450 entries), just run the data loader against the file, specifying Attachment as the object to upload into, and let it run. Those files will be attached in the Notes & Attachments section for each product.

 

From there, it's easy to write your Sites.com page to query for relevant attachments to the product, and display those as images on the page. A naming convention might help you determine how to show which size you're looking for, since you can't really read raw binary data. For example, the name of each file might be "A-0.ext", where A is S, M, or L, and 0 is 0, 1, or 2 (or 1, 2, and 3), and "ext" is the extension of the file. This avoids having to make an effort in filling out fields and so on. Let the metadata drive itself, so to speak.

 

Of course, this is just one possible means of doing this, but see where it takes you.

All Answers

sfdcfoxsfdcfox

I had built a solution once where there was a one-click upload for a file to a product; it would be uploaded as an attachment to that product. Furthermore, I had a custom field (text) that would contain the record ID of the current product image to display (which was actually displayed via a second field, a formula, for display on the product page itself, or in reports).

 

The images could, and should, be formatted by the site page by specifying a height or width. All modern browsers will happily determine the opposing metric necessary to maintain the aspect ratio. Of course, if you specify a height and width, then the browser will stretch the image to fit the bounding box. I'd advise against this, unless you're sure your client will be uploading images that are of the same ratio. You could, however, use some CSS trickery to make a bounding box that would crop the image to a precise dimension.

 

So, here's what I'd suggest. Create a CSV file that contains the following data:

 

ParentId, Body, Name, ContentType

(Product2Id),C:\PATH-TO-FOLDER\IMAGE.EXT, "Product View 1.EXT","image/legal-mime-type"

 

Once you have this CSV, about 451 lines long (header and 450 entries), just run the data loader against the file, specifying Attachment as the object to upload into, and let it run. Those files will be attached in the Notes & Attachments section for each product.

 

From there, it's easy to write your Sites.com page to query for relevant attachments to the product, and display those as images on the page. A naming convention might help you determine how to show which size you're looking for, since you can't really read raw binary data. For example, the name of each file might be "A-0.ext", where A is S, M, or L, and 0 is 0, 1, or 2 (or 1, 2, and 3), and "ext" is the extension of the file. This avoids having to make an effort in filling out fields and so on. Let the metadata drive itself, so to speak.

 

Of course, this is just one possible means of doing this, but see where it takes you.

This was selected as the best answer
jygjyg

Thanks, sfdcfox.  I set this as the solution since this is a great idea and certainly will work.    

 

My only disagreement is your statement that images "should" be fomatted by the site page.  IMO, this should be done server side, either by storage or on the fly, preferably stoage (of pre-formatted images). 

 

I have actually done something similar in the past, and so my actual question was for generating something that my customer could do on her own, simply, as one would do with a (real) CMS.    I think this will just be difficult until Apex gets an image manupulation API and Salesforce gets a true image field.   I feel it is too much to ask customers to upload an image, figure out the URL, and then paste it in another field, and have to do it multiple times for variations on the same image.   

 

You have, however, jogged my imagination.  What I might end up doing is to create a VF element for the object layout in question which would allow the upload of an image and attach it to the currently viewed record as an Attachment, filling in the analogous fields, etc.  If I can make it generic enough, I might as well share it here.

 

 

sfdcfoxsfdcfox

If you took the Flex or Java Applet route, you could perform your image scaling/processing/etc in the browser in real-time, and once the user is satisfied with the results, your code could then save the file programmatically via the API. I also believe it'd be feasible to use the AJAX Toolkit with some HTML5 magic (canvas and the file API), plus a compression library, to make a pure native solution. You could also set up a REST-based or WSDL-based callout that takes an image and some parameters and returns a formatted image. Like I said, there's plenty of possible options. As you said, it's unfortunate that there's no native Apex Code support for manipulating images, but there's a plethora of options.