Using Dojo in the Spring WEB MVC Environment

Before you start

About this tutorial

This tutorial explores how to use the Dojo widget in the Spring Web MVC environment, with the example application using Dojox.data.DataGrid, a dojo Toolkit 1.2 new widget. There are many different formats for exchanging data between Dojo widgets and servers, and this tutorial focuses on comparing data in JSON format that is commonly used in Ajax programming. This tutorial example demonstrates the details of exchanging data between the Dojox.data.DataGrid component and the spring Web MVC controller, where the server side uses Spring Json View to render the JSON data.

Prerequisite

This tutorial assumes that the reader is already familiar with the Spring Web MVC and can configure the appropriate environment. However, there is no specific requirement for dojo Toolkit, and the tutorials will detail the relevant dojo knowledge.

System Requirements

The examples in the tutorial use the following tools and environments:

JDK 1.6.0+

Dojo Toolkit 1.2

Spring Framework 2.5.5 and its dependencies

Apache Maven 2.0.9

Tomcat 6.0.14

Eclipse 3.4.1

Apache HTTP Server 2.2

Spring Json View

The example uses the Apache Maven Jetty plug-in, and if a partial dependency installation is not successful during the run, ask the reader to find the appropriate URL from the reference resource, download it manually, and install it into the Maven local repository.

Dojo.data Foundation

In the traditional desktop MVC pattern, the decision view content is the model, and when the data of the model changes, the controller (Controller) generally emits instructions to refresh the view, and the model plays a driving role in the desktop MVC pattern. MVC for the web reverses the drive order of the views and models, and Web MVC is accessed by the client on the view, prompting the controller to extract the corresponding data from the model, where the view plays a driving role. This feature of Web MVC is determined by the characteristics of the network protocol itself, and it is impossible for the server to know what data the customer needs before the client accesses the corresponding view.

In the development of WEB applications, we are accustomed to the view-driven MVC pattern, and the emergence of Ajax toolkits such as Dojo is back to the traditional desktop MVC pattern, and the driver is transformed into a model. The role of Dojo.data in the Dojo Toolkit is equivalent to the model in the desktop MVC model, and the various Dojo widgets are equivalent to views. Using the Dojo widget requires only a tag declaration and a model that provides the data in the attribute, other things are done by the framework, and the widget is updated as soon as the data associated with the widget changes.

Features in Dojo.data (features)

Java or C + + is based on class to implement object-oriented (object oriented), JavaScript is also object-oriented, but its implementation mechanism is very different, for this, this tutorial does not want to delve into. In order to better understand the feature in Dojo.data, it may be a Java programmer's perspective. Skimming to achieve technical differences, the feature in Dojo.data is equivalent to the interface in Java (interface). The later part of this tutorial treats the feature (feature) as a synonym for the interface (interface), but in fact the two are not the same, please keep in mind.

The feature in Dojo.data have the following four kinds:

Dojo.data.api.Read defines a functional interface for reading data from a data source.

Dojo.data.api.Write defines a functional interface for adding, modifying, and deleting data entries (item).

Dojo.data.api.Identity requires that each item data in the data source must have a unique identifier (much like a primary key in a relational database table), dojo.data.api.Identity The provided function interface provides quick access to the corresponding data entry (item) based on the identifier.

Dojo.data.api.Notification defines an interface for event handling that triggers events when a data entry (item) is added, modified, or deleted, and by overwriting the corresponding method in the Dojo.data.api.Notification interface, can handle the corresponding event, which is the same as the traditional graphical interface event programming mechanism.

These four kinds of feature define all the functional interfaces that Dojo.data can provide, and the specific implementation classes implement the corresponding functions according to different data sources. The relationships between these kinds of feature can be represented in UML diagrams, as shown in Figure 1:

Figure 1 UML diagram of four kinds of feature in Dojo.data