Ooyala Flex Objects

What is an Object?

Ooyala Flex is an “object-orientated” system. This may seem like confusing jargon but humans think in terms of objects (or things), and it’s a natural way to view the world around us. The real world is full of objects such as chairs, tables, windows, cars - the list goes on. Objects comprise properties that define their state. For example: a car object might have a colour property, a velocity property and a window has a width property and a height property. Some object types are related to each other and some object types comprise other object types. For example a car has multiple wheels.

Ooyala Flex supports a range of object types. Examples of object types are asset, workflow, and user. Each object type has its own properties. Object-specific properties are captured with a metadata schema that defines the data fields (properties) associated with that object type.

As well as supporting existing object types, Ooyala Flex allows users to create their own custom object types (business objects), as well as customise existing object types (variants).

The fact that Ooyala Flex allows users to create their own object types, with associated fields, and define relationship between objects, means that Ooyala Flex can be used for modelling anything. As a result of this, Ooyala Flex can be used to integrate deeply into wider business systems and support more than simply assets. Examples might be rights, scheduling or account data.

Access control is used to control access to objects at the user and account level. This access control allows multiple users with different roles to safely and securely interact with each other and objects on a single Ooyala Flex platform.

Object Properties

One of the most important concepts to understand in the Ooyala Flex platform is that nearly everything is an object. There are various object types in Ooyala Flex. Examples include assets, workflows, and tasks. Objects in Ooyala Flex comprise the following properties:

  • Many built-in object types have dashboard section views (assets, workflows etc.)
  • You can use “New” in the Navigation panel, to create a new object. Or you can use the API.
  • Objects always have their own immutable and unique system-assigned id.
  • Objects have a name and a description.
  • Objects always have only one owner.
  • Objects always belong to only one account.
  • Some object can be nested in hierarchies.
  • An object has “created” and “last modified” dates.
  • All object types can be searched by the same set of fields (general search options).
  • Some objects can be enabled, disabled and deleted (deleted objects can still be searched).
  • Some objects can be started and stopped.
  • Some objects can be imported and exported.
  • Objects support attachments, user comments and history.
  • Objects support references to other objects.
  • You can add and remove shortcuts to objects.
  • You can follow and un-follow an object, and be notified of changes made (as well as comments added).
  • You can view object history.
  • Some objects have metadata schema (custom data) associated with them.
  • Some objects allow you to create variants, so you can create custom sub-types.
  • Some objects have context where environmental variables can be stored and read.
  • Some object support being approved and un-approved.
  • Some objects can be locked and unlocked.

One of the benefits of nearly everything being an object is that once you learn one Ooyala Flex object type, such as an asset, you’ve automatically learned a lot about all other object types in Ooyala Flex.

It’s worthwhile taking the time to learn the properties of objects listed above as it is the key to understanding Ooyala Flex. One benefit of Ooyala Flex’s object-based approach is that the screens for objects are similar across object types and it also makes the API very easy to use. For example, the summary screen for an asset has similar fields and layout as workflow instance summary screen.

Object Names

Some object types enforce rules relating to the uniqueness of their name. In the case that an object type enforces unique names, an error message will be shown asking the user to select a unique name if the name entered is the same as an existing object name. For example if you have named an asset “Test Asset”, you cannot give that name to another asset.

Some object types enforce uniqueness on a per account basis. A good example of this is the user. A user’s name must be unique within an account.