Itemscript 1.0 adds JAM templates, the Itemscript Validator and the Item:Store for GWT developers.

Petbase is a JAM application that manages information about pets and their owners. This demo version runs in memory (any changes you make will not be saved):Petbase is a GWT application that’s written in JAM (JSON Application Markup).

JAM (JSON Application Markup)

JAM uses JSON expressions to describe rich web applications.  JAM directives are applied at runtime to provision the Item:Lens, a GWT client that transforms JAM into HTML and manages events to provide a rich web experience.

JAM expresses itself using name:value pairs, in JSON format.  For example, this places an image on a page:

{“image”:”pet.png”}.

The “image” declaration tells the Item:Lens to load the widget named “image” and the “pet.png” directive passes in the name of the image.

The Item:Store API

JAM applications interact with data using the Item:Store API.  The Item:Store API addresses data by location.  The Item:Store API describes a simple REST interface to data in memory or at an external data source.  You can use the API to sync the external source to the location.

For Petbase , we’ll assign “com.petstore” as the location to hold Petbase data.

JAM applications address items by location using a URL.  This hides the complex data source API from the JAM developer. This provides a level of separation so the data source can change without affecting the JAM application.

The Itemscript schema

The Itemscript schema describes the data at a location.  For example, this schema describes the type “Dog”:

"com.petstore.Dog" : {
        "name" : "string",
        ".optional age" : "integer"
        "owner" : "string",
        "breed" : "string"
}

and this location (“com.petstore.Dog.Name.Fido”) describes a dog named Fido:

{
        "name" : "Fido",
        "owner" : "Steve",
        "breed" : "mutt"
}

Why JAM?

JAM provides a layer of separation between the application definition and the resources that bring it to life.  YAML is in some ways comparable to JAM, but YAML doesn’t concern itself with data source integration.  UIBinder is comparable to JAM but is a compile time implementation based on XML.  JAM is a runtime binding expressed in JSON.

A rich web application is a complex package of client side code, server side code and a client/server connection code.

  • Client side developers typically use Javascript, HTML, CSS and perhaps SQL to express the user interface, handle events and keep the client sync’d to the servers.
  • Server side developers typically use a MVC (model view controller) to receive requests from the client and respond with pages to be displayed.
  • Database developers provide relational views or generate objects from relational data to handle data movement between client and server.

Many skills are needed to bring an application to market.  When the interface developer discovers new data, this has a ripple effect as the server side and database developers update their components.

JAM and the Item:Store API were designed to remove this bottleneck by making it possible for the interface designer to build live application models on the client, test and validate their usability, then bring in technical developers to integrate the server side.

With JAM, the developer can declare and manage data without connecting to a live data source.  This defers the cost of connecting to servers.

With JAM, the developer can manage the application state on the client side instead of connecting to an MVC framework.

And with JAM, the application provides a rich web experience that eliminates all but necessary page reloads.

This is a brief description of JAM and the Item:Store API.  If you’d like to know more, download the Petbase demo and write some JAM.