At the simplest level the asset manager provides a way for users to upload and organise files. Within the CMS the assets will be used as content in the front end, but will also be available for other parts of the system. For example a web-shop would need to have images for products.

So, there are two ways to design this. One is to make assumptions about what we need it to do and just hack it together. The danger there is that we can’t know how we’ll need to use it in the future. When adding custom components to the CMS it’s likely that some will need to access the assets.

• AssetLibraryModels
• ContentMixin
• ImageResizing
• Browser?

API

The answer is an API which all the components in the CMS use to access the assets — this includes inbuilt components like the content management.

This is only a guess at what the API could look like:

A UI component for browsing . This would be called in the controller. Additional options may be passed in to limit what it displays.

@browser = AssetLibrary.browser(:collections => :all, :types => [:image])

Then, the actual interface can be rendered in a view

= @browser.render

When specifying a particular asset we want to use — attaching it to content in the site for example — we may need to pass in additional options

AssetLibrary.use(205, :size => "300x200>")

This tells the asset library that we need the image to be in that size. If it doesn’t have an image in that size already, it can the start resizing it in the background.

Whenever an asset is updated — the actual file, not it’s meta-data — each registered component in the system will receive a call to the using_assets? method. In this way we can ask components which assets they’re using and what options they need — size etc.

Need to think about how this using_assets? method could work and what it needs to return. Initial thoughts; a hash. Keys are the asset IDs. Contents is either false — meaning they’re not used by this component — true, or a hash of options. The options are what is then used by the asset library to reprocess the asset — if needed.

{205 => false, 353 => true, 429 => {:size => "300x300>"}}

How the component derives that information is totally up to it. It’s responsible for keeping track of what components it’s using.

Searching and Browsing

Collections

A collection is way of organising assets. They don’t behave like folders. The assets sit in a flat namespace. Collections are just a way of grouping related assets. An asset may belong to multiple collections.

Searching

Obviously users will want to be able to search. It should look in the asset name, description and perhaps for text-documents, the actual content — this could be done by parsing the content on upload and stashing it in an indexed_content field or similar.

Browsing

When selecting an asset to attach to a page, we need a dialog which allows the user to browse and search for an existing asset. They also need to have the option of uploading a new asset from the same dialog. When the user has completed using this dialog, it returns a asset id.

Uploading

• Extract meta-data from files where possible — exif in images etc.
• Store file sizes
• Generate previews
• Store on disk, organised by locale/dialect

Processing

Some assets will need to be processed post-upload. Initially this would just be images. We would need to generate a thumbnail to be used in the browser, but we may also need to process custom sizes as needed by various components in the system.

For example if we update an image, we need to check the various sizes that it’s being used at and reprocess them.

Implementation Notes

Assets consist of an Asset model which has n AssetLocalizations. The localization models contain a localized description of the asset and point to the localized version of the file — say a splash image which has translated text for each locale.