public interface ClientServerIntegration
First you must create
DataSources that describe the objects from your
object model that will be loaded or manipulated within your application. All of Smart GWT's
most powerful functionality builds on the concept of a DataSource, and because of Smart GWT's
databinding framework (see
DataBoundComponent), it's as
easy to create a DataSource that can configure an unlimited number of components as it is to
configure a single component.
DataSources provide a data-provider agnostic API to Smart GWT Visual Components that allow them to perform the 4 CRUD operations (Create, Retrieve, Update, Delete). By "agnostic" we mean that the implementation details - the nuts and bolts of how a given DataSource actually retrieves or updates data - are unknown to bound Smart GWT components. One effect of this is that DataSources are "pluggable": they can be replaced without affecting the User Interface.
When a visual component, or your own custom code, performs a CRUD
operation on a DataSource, the DataSource creates a
(DataSource Request) representing the operation. "Data Integration" is the process of
fulfilling that DSRequest by creating a corresponding
DSResponse (DataSource Response), by using a variety of possible
approaches to connect to the ultimate data provider.
There are two main approaches to integrating DataSources with your server technology:
Server-side integration: DataSource requests
from the browser arrive as Java Objects on the server. You deliver responses to the browser by
returning Java Objects. The various server-side integration possibilities are discussed later
in this article.
integration: DataSource requests arrive as simple HTTP requests which your server code
receives directly (in Java, you use the Servlet API or .jsps to handle the requests).
Responses are sent as XML or JSON which you directly generate.
Smart GWT supports, out of the box, codeless connectivity to various kinds of common data providers, including SQL and Hibernate. Smart GWT also provides functionality and tools for accelerated integration with broad categories of data providers, such as Java Object-based persistence mechanisms (JPA, EJB, MyBatis, in-house written systems), and REST and WSDL web services in XML or JSON formats. Ultimately, a DataSource can be connected to anything that is accessible via HTTP or HTTPS, and also to in-browser persistence engines such as Google Gears.
Choosing a Data Integration Approach
This section aims to help you decide which of the many possible data integration approaches is best for your particular circumstances. The recommendations given here will guide you to the approach that involves the least effort.
SQLDataSource vs JPA/Hibernate in order to
understand the large benefits the SQLDataSource provides
autoDeriveSchema feature, or
from Java Beans via the
schemaBean feature. Or, use
Admin Console to generate tables from
DataSource definitions you create by hand
schemaBean feature to derive DataSource definitions from any Java bean
custom DataSource that
provides the CRUD operations you want to support.
DMI, or any combination of the
OperationBinding allow you to dynamically set data values
at transaction-processing time, using built-in
validate() method of the DataSource to provide extra custom validations
- just call
super to obtain the list of errors derived from Smart GWT
validations, then add to that list as required with your own custom code
execute() method of the DataSource to add extra processing
either before or after the Smart GWT processing
Transaction Chaining to dynamically set
data values according to the results of earlier transactions
SQL Templating to change,
add to or even completely replace the SQL sent to the database, and to implement
special query requirements
custom JQL queries to
implement special query requirements
custom HQL queries to
implement special query requirements
the server integration overview.
RPCs: Unstructured Server Communication
Smart GWT also supports "unstructured" client-server operations. These
RPCRequests (Remote Procedure Call Requests) are a low-level,
very flexible mechanism for custom client-server communications. In an nutshell, RPCRequests:
RPCManager.send()), and have their responses handled
by custom code (the callback passed to
relatively rare. Most client-server communications are better done in a structured fashion
DSRequest (DataSource Request). Note that
any RPCRequest can alternatively be framed as a
DataSource fetch; depending on the
circumstances, this may be more convenient.
RPCManager documentation for further information on RPCRequests.