This chapter attempts to give you a general understanding of the architecture of the Mojito Framework. Our hope is that having a better understanding of how the pieces work together and what role they play will help you design, build, and debug your Mojito applications more effectively.
Before looking at the details of Mojito, let’s take a look at how Mojito fits in the Web application world. In the diagram below, the triangular symbol formed with three circles represents the Mojito MVC core; the circles represent the model, view, and controller. This common MVC core executes across devices and on both client and server and is one of the key elements which gives Mojito its power. As the diagram illustrates, Mojito runs on various clients, uses HTTP for all client-server communication, and typically accesses data with the Yahoo Query Language (YQL) due to its power, ease-of-use, and ability to run from either the client or server.
Mojito was designed with the goal of running in multiple runtime environments and supporting online and offline experiences. The following are the supported client/runtime environments:
A Mojito application is, quite simply, a set of module/widget components (called mojits) bound together with one or more JSON configuration files which describe the application model, view, and controller code used depending on context. A Mojito application is packaged to be distributed and deployed as a unit, and as such, it is deployment-independent. The mojits used by an application may be included directly within the package or may be included by reference from a cloud-based repository.
See also Mojito Applications for a more in-depth discussion.
To support seamless operation and migration of components between client and server, Mojito application data is typically obtained with YQL. In most cases, your data will be requested and processed in some way before it is presented to the user. JSON is expected to be by far the most prevalent format for data retrieved from YQL.
The Mojito Framework consists of both module-level and application-level framing, which taken together provide the infrastructure upon which applications are built. Mojito framing includes the base component framework, the event system, and management of navigation, views, and configuration. Mojito is built directly on top of YUI and can be considered an extension of it.
This diagram shows the relationships among the Mojito application, the Mojito Core, mojits, and the runtime environments. The subsequent sections describe the elements in the diagram in more detail.
The base server-only capabilities that support the Mojito Core include, but are not limited to, the following:
The base client-only capabilities that support the Mojito Core include, but are not limited to, the following:
The Mojito Core is the common functionality of Mojito that runs on both server and client. The core is initialized (or bootstrapped, if you will) by either the Mojito Server Runtime or the Mojito Client Runtime, as appropriate. Elements of the Mojito Core include, but are not limited to, the following:
The Mojit Container is where mojit instances live. This is analogous in a traditional Java Web framework to the servlet container. In Mojito the component container logic runs in both server and client contexts. Mojit container logic includes, but is not limited to, the following:
The “API” block of the diagram represents the common API object provided to each Mojit. This common API object is properly referred to as the Action Context. A unique ActionContext object is available to each mojit instance to enable it to do its work. In a traditional Web framework, this is analogous to the request context (except, of course, that there is no request object when the mojit is running within the client).
The Services block is a customizable layer within Mojito, typically created with a combination of custom middleware and ActionContext addons, which allow your applications to make use of common services. Mojito does not make any presumptions about required services, but instead provides the means for reusable services to be developed as extensions to the core framework.
The View Factory creates the view instance for a mojit instance based on a mojit’s configuration and on its corresponding mojit definition. The following standard view types are provided, along with the capability for a mojit developer to define a custom view type:
The View Cache provides applications with the ability to cache. For example, because of the View Cache, an application can cache partially rendered views to improve performance in situations where the same partial rendering is frequently requested.
Box A in the flowchart below represents the Application Container at its most basic level. Here we focus on the servicing of page requests and user interactions, and ignore for the moment issues such as packaging and deployment. Again, we examine more closely the framework components in the following sections.
This component processes incoming URLs and determines how to map these to the appropriate application functionality. This is similar in many ways to the front controller used in most action frameworks. The target functionality is almost always provided by a mojit, and thus, the Dispatcher primarily maps URLs to mojit identifiers.
The mojits themselves are not part of the Application Container per se. The container provides the facilities to host, support, and manage mojits while the mojits collectively provide the functionality of the application. See also Mojits for more information about mojits.
A particular instance of the Application Container is initialized through an externally managed configuration. This configuration includes, among other things, the mappings that drive the Dispatcher, the identification of necessary mojit registries, and other environmental parameters. The Application Configuration, however, specifically excludes deployment parameters because it is part of the packaged, deployable application, and therefore, must not be tied to a particular deployment environment.