This technical article was first published over 2 years ago and may discuss features and approaches that are no longer relevant for the current version of the platform.

EPiServer 7.5 delivers a completely new digital media management system offering a host of editor enhancements, including integration into the new editing interface, multiple file drag and drop file upload, inline media preview, and drag and drop placement of media into ContentAreas and the Rich-Text-Editor.

From a developer perspective, much has changed too. Media files are not stored through a Virtual Path Provider but as a Blob (Binary Large OBject). This allows media assets to be stored and used in true elastic cloud scenarios, though the default blob provider still saves media files to disk (just as the old VPP system did).

Also new, is that media assets are now treated as first class content items. That is; they inherit from the IContent interface and have code definable properties allowing better definition of media meta data. This is now defined in a strongly typed manner just as you do for other IContent items such as pages, blocks and catalogue nodes and items in Commerce.

Image size validation

A media item has a one-to-many mapping to a file extension, so EPiServer will only associate one IContent class with a particular file extension or collections of extensions. A basic content handling of media data is included in the Alloy Templates demo site, and includes three new IContent classes, inheriting from the core VideoData, ImageData and MediaData objects.

This one-to-many mapping means you have to take a slightly different approach to content modelling media items than you do for page or block types. For example, you may want to have banner images that must have a particular size, or a photo image that requires additional meta data than a standard image. For now you can’t do this. All files of a particular extension have to contain the same metadata.

This means that you cannot validate images for size when you upload them (as you’d restrict every single image with that extension to be that size). Although this feels restricting, it is perhaps the correct decision as media size only matters when you display your content (and although it hasn’t has much love recently, EPiServer does offer an online image editor). It is only when you use your image within a particular presentation layer (page /block) that you really need to constrain it to a definite size.

Validating an image used in context

You can apply validation to any property used within a page or block type via a validation attribute. Media assets are stored as content references in a page or block; with a specific UIHint attribute to allow the editing system to know that you require an IContent inheriting from ImageData.

I’ve put togther a validation attribute that you can add to a ContentReference property which will validate the size of any ImageData content referenced in that property.

[UIHint(UIHint.Image)]
   [Display(GroupName = SystemTabNames.Content,Order = 3)]
     [RequiredImageSize(Width = 300, Height = 100)]
     public virtual ContentReference Image { get; set; }

You can specify a height and or a width in pixels. Currently you can only apply this to ContentReference properties but I can see it would also be useful to apply it to ContentAreas – I’ve just not got round to that yet.

Image Validation

The source code is available at https://github.com/markeverard/Chief2moro.ImageDataExtensions

A package containing this validation attribute, along with some other image related goodies that I’ll blog about soon, is available in the EPiServer Nuget Feed – http://nuget.episerver.com/ – search for CHIEF2MORO.ImageDataExtensions