The basic unit of composition and reuse in a Mojito application is a mojit.
Visually, you can think of a mojit as the rectangular area of a page that was
constructed by a Mojito application.

The following sections explain why we chose the name mojit and then examine
the mojit’s architecture and structure. This chapter is meant as an overview
of mojits and does not show how to configure, create, or use mojits. For those
implementation details, see the following:

There are (at least) two very commonly used names given to the basic portions
of a page, site, or application, viz. module and widget. Depending upon
the context, each of these terms will be interpreted in different ways by
different people. In the hope of alleviating misinterpretation, we have chosen
to create our own word: mojit (derived from module + widget and pronounced
“mod-jit”).

From the diagram below, you can see that the mojit has an MVC structure
centered around the Action Context
and can be deployed to the client or run on the server. Also note that the Mojit Proxy
allows client-side code (binders) to communicate with server-side code through the
Action Context. The sections below describe the main components in the diagram that
are shaded in green.

Binders are mojit code only deployed to the browser that can
allow event handlers to attach to the DOM node, communicate with other mojits
on the page, and execute actions on the mojit that the binder is attached to.

Models are intended to closely represent business logic entities and contain code that
accesses and persists data. Mojito lets you create one or more models at the
application and mojit level that can be accessed from controllers.

View files are called templates in Mojito. Templates can contain both HTML
and templating tags/expressions, such as Mustache or Handlebars, and are rendered into
markup that is outputted to the client.

One of the key characteristics of mojits is that portions of their code may run
in different environments, depending upon particular attributes of the client
runtime. Specifically, while the raw HTML rendering and event handlers always
run within the client, the remaining portions (such as template
processing) may run within the client, if it is sufficiently capable, or on the
back end, if it is not.

Mojits are built using a variant of the MVC pattern. The Controller
encapsulates the core functionality of the mojit, reacting to stimuli from the
Active View (see diagram above) and possibly from outside of the Mojit. The Model
centralizes the representation and management of the Mojit’s data. The
Active View provides for presentation and user interaction.

The combination of a mojit’s view together with its user event handlers (as
distinct from system event handlers) is called its Active View. The Active View
is that portion of a mojit that always resides within the client, in order to
provide the actual presentation together with the immediate event handling that
makes the mojit responsive.

The event handlers within the Active View are intended to be very “thin”; they
perform translation of user gestures to mojit capabilities (e.g., button click
to “item select”) and subsequently delegate to the mojit’s controller. This
allows for the Active View itself to run in less capable environments.

A mojit definition is a set of artifacts that collectively define a reusable
unit of functionality known as a mojit. A mojit definition includes the mojit
implementation (e.g., JavaScript code, template files, CSS, etc.)
and has the following characteristics:

uniquely identified, and thus, capable of being referenced from and shared
within multiple applications.

The term mojit instance actually has two distinct meanings. The
meaning though should be quite clear from the context within which the term is used.

Mojit instance can refer to a specification of all the information required
to create a running instance of mojit functionality within an application. This
is essentially a specification that comprises the identifier for a mojit
definition together with the concrete configuration parameters that will be
used to instantiate a particular instance at runtime. You can learn more about the
specification for a mojit in Mojit Configuration.

Mojit instance can also refer to an in-memory runtime instance of a mojit—part
of the running application.

Mojits may be designed to be nested. That is, a mojit may be a “child” mojit, a
self-contained unit of presentation, or a “parent” mojit, one which may
itself incorporate other mojits in order to fulfill its role. Composite mojits
encapsulate their children, such that, for all intents and purposes, an
instance of a composite mojit cannot be distinguished from its child mojits.

See the chapter Composite Mojits for more
information and to learn how to create composite mojits.