Mojito (framework)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Mojito is an environment agnostic, MVC web application framework architected by Ric Allinson which supports agile development of web applications. Mojito has built-in support for unit testing, Internationalization, syntax and coding convention checks. Both server and client components in Mojito are written in JavaScript which imparts Mojito it's specialty.[1]

Mojito allows developers designing web applications to leverage the utilities of both configuration and MVC framework. Mojito is capable of running on both client(browser) and the server(Node.js) because both client and server side components are written in single language,i.e, JavaScript. Mojito Applications mainly have two components:

  • JSON Configuration files: defines relationship between code components, assets, routing paths, defaults and are available at the application and mojit[2] level.
  • Directories: It reflects MVC architecture and separate resources, such as assets, libraries, middleware, etc.

Overview[edit]

Mojito provides seamless MVC framework to manage code base on server as well as on client side. The advantages of using Mojito are:

  • Single Language: Mojito is entirely built on JavaScript and hence the application code can run on server as well as can be deployed to client. This will remove the need for client to fetch data from the server.
  • Run-time Environment: Mojito has inbuilt capability to determine whether client can run JavaScript before deploying the code. If the client cannot execute JavaScript (JavaScript might be disabled at client side), then Mojito will execute the application code on the server.
  • Internationalization: Mojito has inbuilt library to handle Internationalization and localization.

Mojito Architecture[edit]

Mojito Architecture

In mojito, both server and client side scripting is done in JavaScript, owing to which it can run on both client and servers thereby breaking the front-end back-end barrier.Therefore it has two running times:

  • Client runtime
  • Server runtime

Mojito server runtime

This block houses operation called upon while running application on server side only. Some of these operations are: Routing rules, HTTP Server, config loader, and Disk-based loader.

Mojito client runtime

This block houses operation called upon while running application on client side only. Some of these operations are

  • Local storage/Cache access
  • JSON based /URL based loader

Mojito Core

In addition to Mojito client runtime and server runtime, architecture also has Mojito Core which can be called while running application on client side or server side both. Functionalities hosted into mojito core includes :

  • Mojit Registry
  • Dispatcher
  • Front controller
  • Resource store

Mojit container

This is where mojit object comes in picture. This container also include the services used by mojits. API and Mojito services are the blocks which caters to services needed for execution of mojits.

API(Action Context) block host services which are needed by mojits to carry out its work, whereas Mojito services are the customizable service block. It exposes mojits to a range of services which might be needed by mojit to carry out certain actions.These services can be availed at both client and server side. Reusable services can be created and aggregated to the core here.

Mojits

Mojits are the most basic entity of mojito application. This is where Model, View , Controller in accordance with JSON configuration files are based. Controller manipulates the model by commands. Models contains data according to the commands from the controller. View factory is the place where views are created according to the model. View Cache caches some frequently requested views to aid overall performance.

Mojits[edit]

Mojits are the most basic entity of an mojito application. There can be multiple mojits existing at same time.

Mojit Architecture

A Mojito application is nothing but a set of mojits working with each other and are facilitated by configurable JSON files which defines the code for model, view and controller. This MVC structure of mojit works in close liaison with API block and Mojito services, and can be deployed at both client and server side. While the application is deployed at client side, it can always call modules on server side using binders. Binders basically are mojit codes that lets mojits connect with other existing mojits and execute tasks to accompolish the core functionality. Mojit Proxy acts as an intermediary between binders and mojit's API(application context) block and other mojits. Controllers are command issuing units of mojits. Models mirror the core logic and hold data. We can have multiple models in Mojito application. They can be centrally accessed from controllers.View files are created in accordance with controllers and models, and are marked upbefore being sent to user as output.


Application Directory Structure[edit]

The following shows the directory structure of a Mojito application with one mojit.

[mojito_app]/

|-- application.json

|-- assets/

| `-- favicon.icon

|-- yui_modules/

| `-- *.{affinity}.js

|-- index.js

|-- mojits/

| `-- [mojit_name

| |-- assets/

| |-- yui_modules/

| | `-- *.{affinity}.js

| |-- binders/

| | `-- {view_name}.js

| |-- controller.{affinity}.js

| |-- defaults.json

| |-- definition.json

| |-- lang/

| | `-- {mojit_name}_{lang}.js

| |-- models/

| | `-- {model_name}.{affinity}.js

| |-- tests/

| | |-- yui_modules/

| | | `-- {module_name}.{affinity}-tests.js

| | |-- controller.{affinity}-tests.js

| | `-- models/

| | `-- {model_name}.{affinity}-tests.js

| `-- views/

| |-- {view_name}.{view_engine}.html

| `-- {view_name}.{device}.{view_engine}.html

|-- package.json

|-- routes.json (deprecated)

|-- server.js


MVC in Mojito[edit]

Model, View and Controller: the three components of a MVC architecture are simply represented in Mojito. Controller commands all the interactions in the MVC of Mojito and therefore is central to the framework. Controller also garners data from Model and progress it to the view so that view can render the data. Controller has one more function which is to handle any client requests for data, in which case controller fetches data from the model and passes the data to the client.

All the three components: model, view and controller are clustered together in the mojit (single unit of application) of Mojito. Mojits are physically illustrated by directory structures and an application can have multiple of mojits associated with it. Every mojit can have one controller, one or more views and any number or no models.

Below we have each MVC component illustrated in more detail:

  1. Model: it represents the data of the application and is independent of view or controller. Model also contains code that can manipulate the data. They are found in the models directory of each mojit. Some of the functions of models are:
    • retrieving information and sending it to controller.
    • Validation and error handling.
    • includes properties of the data that is required by the view, and populates itself.
  2. Controller: acts like a connecting agent between model and view. It supplies input to Model and after fetching data from model, passes it to View. Controllers are found in mojit directory. Some of the functions of controllers are:
    • handles redirection
    • monitors authentication
    • web safety
    • encoding
  3. View: acts as a presentation filter by highlighting certain attributes of the model and suppressing others. A view can be understood as a visual representation of the model. View renders data received from controller and display it to the end user.

References[edit]

  1. ^ "Introducing Mojito". Retrieved 16 June 2012. 
  2. ^ "Mojito Applications - Yahoo Developer Network". developer.yahoo.com. Retrieved 2016-09-13.