Architecture

Contexts and Deliverables

The model architecture is based around a primary "Deliverable", which contains one or more "Contexts". Deliverables are typically things like a page, or a blog post, but can be anything which contains multiple Contexts.

Contexts can be any type of structured content. Examples could be headings (h1-h6), general text blocks (paragraphs/lists/basic formatting), audio files, videos, image galleries... or any other content which can be described in HTML. Each deliverable has a has_many relationship to a collection of contexts, which can be organized and arranged in any particular order.

As an example, consider a Post deliverable, containing content and a video:

<article id="post">
    <h2>The Post Title</h2>
    <div data-context-id="xxx" class="content">
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit....</p>
    </div>
    <h3 data-context-id="xxx">A Sub Heading</h3>
    <video data-context-id="xxx" src="some_random.mp4" poster="poster.jpg" />
</article>

In the example above, the Post's contexts would consist of:

1. the body copy (div.content),
2. the sub-heading (h3),
3. a video.

Items like the post title (h2) would be described within the Post itself. A JSON representation of the Post "Deliverable" would be as follows:

    {
        "id" : 1,
        "_type" : "Post",
        "title" : "The Post Title",
        "contexts":[
        {
            "id" : 1,
            "_type" : "TextBlock",
            "body" : "Lorem ipsum dolor sit amet, consectetur adipisicing elit....",
            "position": 1
        },
        {
            "id" : 2,
            "_type" : "Heading",
            "body" : "A Sub Heading",
            "node" : "h3",
            "position": 2
        },
        {
            "id": 3,
            "_type" : "Video",
            "source" : "some_random.mp4",
            "poster" : "poster.jpg",
            "position": 3
        }
        ]
    }

Each model, whether deliverable or context, contains a _type attribute (yeah, we use Mongoid a lot) which represents the type of model to be used. This is particularly useful when data is loaded, as Transit will automatically map each item to the appropriate Backbone model within your app (falling back to a generic Context model) before adding it to the deliverable's contexts attribute. Contexts also include a position attribute, which determines the ordering of each context within the deliverable.

The id, _type and position attributes are the only two that are required, additional attributes would be dependent on your particular integration.

Transit also includes an Asset model, which is used for general, user-uploaded files and images.