Ticket #1572 (new enhancement)
Better handling of different media types
| Reported by: | sminnee | Owned by: | ischommer |
|---|---|---|---|
| Priority: | medium | Milestone: | |
| Component: | CMS - Files and Images section | Version: | |
| Severity: | medium effort / impact | Keywords: | |
| Cc: | Hours: |
Description
There isn't much support for dealing with media other than images. There are two things that would be nice to do better:
- When including a download link, show a little widget indicate file type and file size.
- When inserting a video, display it inline
There are two places where these could be used:
- When you are editing content, let people insert these representations of files into the content.
- When referencing a File object programatically or in a template, be able to get this representation and insert it into the code.
One way of achieving this is to have an Inline() function on the File object, that would return the HTML to be inserted for representing this object Inline.
But, how do you decide what the Inline() function returns? There are a few factors that will be relevant here:
- The system needs to be extensible, so that 3rd party developers can come up with alternative representations for files, for example, a new video-inlining mechanism.
- The most basic decision-making factor would be the file extension. We could do more fancy stuff if we were able to have more complex decision-making factors, but file extension would be acceptable as a minimum.
- We would need to support a default handler.
If we were to stick to solely choosing a handler based on file extension - and I think this is a good move - we could
- Create a base class, FileFormatter?, that had an abstract function static format_inline(File $file)
- Create a static function File::register_formatter($extensionList, $formatterClass, $priority), that would be responsible for registering the formatters that could be used. $priority would give us a way of deciding which formatter should be used - letting a module or project-specific code override the formatters defined by default.
The File class would maintain a static array of $registered_formatters, that it would use to identify which formatterClass to use, and then call a function such as this to return it:
function Inline() {
$formatterClass = self::$registered_formatters[$this->Extension]['className'];
return eval("return {$formatterClass}::format_inline($this);");
}
If people wanted to define formatters that used more sophisticated criteria than file extension, they could do so in their format_inline() function.
Once we have such a system set up, template authors can put $MyFileField?.Inline in their templates. To get the inlining working in the WYSIWYG editor, we would need to set up some kind of interface with an AJAX call to FileObj?.Inline().
