Setting up a media type field for image and application fields
From Designer 7.7.3, image and application fields have a new property: Media type tag on the Image properties and Application field properties tab respectively.
Previous to Collections 1.11, linked video and audio files displayed broken-link icons in front of records in the Result set and Gallery views (although the files displayed or played fine in the Media Viewer), if no proper thumbnails could be generated, as is the case for audio and video files, or documents for example.
From Collections 1.11 though, if properly set up and if media types are registered together with media references in the records, then for file identifiers without file extension (which could occur when media files are retrieved via the WebAPI or a DAMS), instead of broken-link icons, the following generic icons will display for audio, documents, images and video files. These icons will also be displayed without proper setup or registered media types if the media type can be distilled from the file name extension while still no proper thumbnail can be generated.
So if the registered media files in your application all have a file extension, like .jpg, .doc, .mp3 or .pdf for example, you don't need to change anything to the setup of your image and application fields: Collections 1.11 will automatically notice and recognize the file extension and if it can't create a proper thumbnail image, one of the above icons will be displayed in the Result set and Gallery views instead.
If, on the other hand, most or all of the registered media files in your application do not have a file extension, because they are identifiers for files retrieved from a DAMS, for example, and you would like the above generic icons to be displayed instead of no icon (!) at all when no thumbnails can be generated, then you will need to do some set up, as follows:
| 1. | You will need to create new, repeatable text field per image or application field in every database for which you like the new generic icons to appear. This field will later contain so-called MIME types (to indicate the media file type) like audio/mpeg or image/jpeg. Make the field length 100. The field needs to be put in the same field group as the relevant image or application field. It doesn't need to be indexed. |
| 2. | For image and application fields linking to the media database table, the new field needs to be added as a write-back field to the linked image or application field so that the MIME type gets written back to the media record too. So the media database table needs to get a media/MIMY type field too. |
| 3. | Enter the new field tag (or look it up by clicking the ellipsis button next to the property box) in the Media type tag property of the associated image or application field. You'll have entered an existing (allowed) tag if it is being replaced by its field name automatically as soon as you leave the property. |
| 4. | It's not required that the field is present on a screen as well, but recommended nonetheless. So put your new fields close to their associated image or applications fields, so that they can repeat together. Make it a writable screen field. Label it Media type or MIME type, as desired. |
| 5. | Repeat the above steps for all desired image or application fields. |
| 6. | Save your changes and recycle the Collections application pool. |
The new setup will make sure that whenever a media file is now uploaded to one of these image or application fields in a record in edit mode, the relevant MIME type will be entered in the Media type field automatically: Collections will extract that type from the file extension or from the file itself if it has no extension. The user won't need to touch that value and Collections will use it to display the proper generic media type icon when appropriate but also to prepare the Media Viewer for the proper media type.
The reason for the media type screen field being writable is that if the above setup has been applied to fields in a database which already has data in it, the user must be allowed to enter the appropriate MIME types in this field manually, if desired. (If all MIME types are the same for a particular field, one could use the Collections Search and replace function for a record selection, to enter that MIME type for a lot of records all at once.) Note that a MIME type registered in the media type field will take precedence over any actual file name extension (if present), when Collections determines which media type icon to display.
Valid MIME types can be found on the internet. Common ones can be found here, for example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
By the way, an actual thumbnail of an image file of which the MIME type can be determined, will only be generated by Collections if it is one of the HTML5 image types (GIF, PNG, JPEG or SVG). Of other file types, no thumbnail can be generated.
Further note that for one or two customers a <MediaTypeTag> element was introduced and implemented earlier (but never documented) in their settings.xml to do the same thing as the new Media type tag field property, but that setting is now deprecated (because it doesn't work in all situations) and should be replaced by using the new field property.
Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.
Feedback
