Last updated June 17, 2013. Created on September 5, 2012.
Edited by henrikakselsen, drico. Log in to edit this page.

At a glance :
The scald core allows developers to unify their media asset thru bundles of entities ( Audio, Video, or one you will define ) using providers and manage them.

Scald Entities

Scald defines a bundle of entities per media type. Those types are registered by the media providers which are separated modules. This is done by this hook:
hook_entity_info : scald_entity_info()

<?php
  $return
= array(
   
'scald_atom' => array(
     
'label' => t('Atoms'),
     
'controller class' => 'ScaldAtomController',
     
'base table' => 'scald_atoms',
     
'uri callback' => 'scald_atom_uri',
     
'fieldable' => TRUE,
     
'entity keys' => array(
       
'id' => 'sid',
       
'bundle' => 'type',
       
'label' => 'title',
      ),
     
'bundle keys' => array(
       
'bundle' => 'type'
     
),
     
'bundles' => array(),
     
'view modes' => array(),
     
'view callback' => 'scald_render_multiple',
    )
  );
?>

Then for each of the defined types of provider ( audio / video / ... ) we loop to define the informations :

<?php
  $types
= scald_types();
  foreach (
$types as $type => $info) {
   
$return['scald_atom']['bundles'][$type] = array(
     
'label' => $info->title,
     
'admin' => array(
       
'path' => 'admin/structure/scald/%scald_type',
       
'bundle argument' => 3,
       
'real path' => 'admin/structure/scald/' . $type,
       
'access arguments' => array('administer content types')
      )
    );
  }
?>

Scald CR(U)D

Scald Atom Shorthand ( SAS )

The SAS version of an atom is the way we use the filtering system to put atoms in textarea:
Any instance of Scald Atom Shorthand (SAS) will be replaced with a rendered Scald Atom. SAS can take any of the following formats: [scald=SID], [scald=SID:context], or [scald=SID:context context-options]. SID is the Scald ID, context is a context-slug, and context-options are additional formatting clues to give to the Context.
Without a Wysiwyg you can include Scald Atom Shorthand such as [scald=12]

Scald Actions and licences

Scald Actions are defined arbitrarily. The possible Actions that a given User can perform on a given Atom are determined by Action bitstrings. Each action has a position (arbitrarily-defined) in the bitstring. Due to PHP limitations, there is an upper bound of 31 Actions. The high bit in any actions Bitstring is the "admin bit" which, when set, means that the comparison is "OR", rather than "AND". Typically a user's Action bitstring (which is an OR-ing of all the Role Action bitstrings which the User is a part of) is AND-ed with the Atom's Action bitstring. However, if the Admin Bit is set, then a user's Action bitstring is *OR*-ed with the Atom's Action bitstring. Careful assignment of Action bitstrings to roles and roles to users should result in a fairly complete set of possibilities.

Scald Display contexts and rendering

Scald Core implements an input filter to allow for the inclusion of Scald Atoms in textareas in Drupal. When defining an input format, care should be taken to ensure that the rendered Scald Atoms (probably rendered in XHTML) are not subsequently processed into oblivion by other input filters. In other words, make sure that the Scald Atom Shorthand (SAS) Filter is *after* filters which strip tags.
The display context are defined thru the hook hook_scald_contexts. We define some in the library module like per example:

<?php
 
return array(
   
// This is the display we use when the atom is drag and dropped in the editor
   
'sdl_editor_representation' => array(
     
'title' => t('Editor Representation'),
     
'description' => t('The Editor Rep'),
     
'render_language' => 'XHTML',
     
'parseable'       => TRUE,
     
'formats'    => array(
       
'image' => array('jpeg', 'png', 'passthrough'),
       
'audio' => array('wav', 'ogg', 'mp3', 'passthrough'),
      ),
    ),
?>

Scald hooks available to other modules

hook_scald_fetch
Used in scald_fetch(), we get the entity from the database then we have the provider put the default information thru this hook.

hook_scald_prerender
We initialize the $atom object in scald_prerender() then we pass it thru:

  • Atom type prerendering
  • Atom providers prerendering
  • An optional transcoder prerendering
  • A contex prerendering

via this hook.

hook_scald_render
hook_scald_rendered_to_sas_xhtml
hook_scald_rendered_to_sas_LANGUAGE
hook_scald_atom_providers
hook_scald_contexts
hook_scald_actions
hook_scald_register_atom
hook_scald_update_atom
hook_scald_atom_presave
hook_scald_atom_update
hook_scald_atom_insert
hook_scald_atom_delete
hook_scald_unregister_atom

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

michaelmallett’s picture

I cannot understand what this means, can you please elaborate

Scald Actions and licences

Scald Actions are defined arbitrarily. The possible Actions that a given User can perform on a given Atom are determined by Action bitstrings. Each action has a position (arbitrarily-defined) in the bitstring. Due to PHP limitations, there is an upper bound of 31 Actions. The high bit in any actions Bitstring is the "admin bit" which, when set, means that the comparison is "OR", rather than "AND". Typically a user's Action bitstring (which is an OR-ing of all the Role Action bitstrings which the User is a part of) is AND-ed with the Atom's Action bitstring. However, if the Admin Bit is set, then a user's Action bitstring is *OR*-ed with the Atom's Action bitstring. Careful assignment of Action bitstrings to roles and roles to users should result in a fairly complete set of possibilities.

scotself’s picture

I've been looking into this for a project and learned some, so hope to help out. This is somewhat complicated, but at a high level what happens is that each atom has the possibility of 4 actions by default - Fetch, Edit, View and Delete. Providers can define additional actions to allow, which then trickle down to the permissions system. The combination of actions that an individual atom has available is stored in the scald_atoms table as an integer (using bitmasking (you can search Stack Overflow or just google this for a deeper understanding).

Now, each atom can be given a default set of "Openly Available Actions" on the /admin/structure/scald/[atom_type] page. Each atom created from that point on will get that set of actions set. This can be overridden on a per-atom basis though, so you can (if you have permission) edit the atom, open it up to deletion, for instance, and then any user who can "Delete any atom marked as Deletable" can then delete it.

The admin portion of the description above is basically saying that anyone with a permission to edit ANY atom will always get that option. I may be mistaken on exactly how this part works, but that should give you a better interpretation of this admittedly cryptic description of the Scald actions system.

I would just update the docs, but would like some sort of validation from the Scald team whether this is an accurate description or not. I'm sure it could be improved, certainly from its current form above...