This project is read-only.

Developer Overview

This page is intended as an overview to the Media Garden framework for anyone interested in developing extensions or plugins for the system.
There are a number of topics to cover and if you simply want to use Media Garden in your Orchard website you should read our User Guide instead.
We have designed the system as a number of interlocking components providing you with all the extensibility points you will (hopefully) need.
Here are the important interfaces and the key reasons you would want to extend them:

Media View

This is an actual renderer / player of media and we imagine this will be the most common type of extension built for Meda Garden.
A viewer declares the media types and formats that it supports; and will then be available in a drop-down list when a media item is edited, or displayed in a container such as the MediaWidget.
Custom UI fields and settings can be established through a MediaViewDriver.
The Media View should always provide a default view template, and additionally alternate templates can be supplied for different media types and formats.

Media Stereotype

This is the broad "high level" categorization of media. For instance: Video, Audio, Image. These translate to different submenus in the Admin menu, and many other components can be filtered on what stereotypes they apply to.
There could be some confusion here between the Stereotype setting of Orchard content items. In fact, media content types are implemented with a special Stereotype setting of "Media" so they can be differentiated from Widgets and ordinary Content in the content manager and Dashbaord UI.

Media Item

This is just a content item in the Orchard database; it's defined by a content type consisting of at minimum the MediaPart, and with a Stereotype setting of "Media".

Media Variation

Describes different versions of the same media item. So you can have an image scaled to different resolutions; or video encoded at different definitions. The IMediaVariation interface can be implemented on a content part, allowing you to describe the custom variation parameters required for your media via that content part's fields.

Media Format

This describes a specific file format within a stereotype. By default it implements a simple set of matching rules by file extension and MIME type but you can provide more complex logic where required; for instance, peeking into an mpeg container to determine a specific codec.
The interface to implement is IMediaFormat or you can inherit the DefaultMediaFormat abstract implementation for extra functionality.

Media Source

Possible renames for clarity: Media Feed, Media Importer, Media Location
This describes somewhere from which we can acquire new media items.
It could be a file system on disk (along with an upload function); or a parser for a specific type of feed; or perhaps database-persisted file storage.
The IMediaSource interface requires you to emit a number of IMediaSourceItem objects which represent the details of the discovered media. It is then the job of other components to map these to actual Media Items in the database.

Media Filter

Possible renames: Media Importer, Media Builder, Media Driver
Filters are the component used during acquisition from a Media Source, to map the discovered data into actual content items, and to perform any additional modification of those items as dependent on the source, format, etc.
This is a very flexible way for you to extend the inbuilt acquisition pipeline, as you can hook in after the items have been actually created and modify them as required before they are published. You could use this to (for example) provide additional data to your own custom ContentParts, pull in extra metadata from a particular RSS feed, trigger conversion of video to other codecs, or a variety of other uses.
IMediaFilter is the interface to be implemented.

Further Information

This is intended to familiarize with the important concepts and interfaces. More detailed documentation will be supplied on the individual components as they are finalized.

Last edited Apr 20, 2011 at 3:20 PM by randompete, version 1

Comments

No comments yet.