public interface ServerDataIntegration
Smart GWT Java Server Framework into any J2SE/J2EE
environment, including any existing web application
create DataSources via an XML declaration,
possibly on-the-fly from
Client-side Data Integration in which
client-side DataSources are configured to send and receive HTTP messages containing XML, JSON
or other content.
Server-side Request Processing
DataBoundComponents will send
DSRequests to the Smart GWT Server as background
communications transparent to the user. Integrating Smart GWT's DataSource layer with your
data model is a matter of handling these DSRequests and sending back DSResponses, in order to
fulfill the 4 basic operations of the
Out of the box, Smart GWT is set up to route all DSRequests through a
special servlet called
Note that the Smart GWT SDK includes detailed Javadoc reference for this servlet and all shipped Smart GWT Java server classes.
that go through
IDACall have the following lifecycle:
RPCManager to manage the processing of the entire queue of transactions. For
every DSRequest in the queue, this RPCManager:
server scripting or
DMI - in other words, your code - and passes the
request to this logic.
As described later in this section, your code can perform some custom logic here: either completely fulfilling the request, or alternatively modifying the request and causing the default processing of the request to continue
execute method to obtain a
This basic request handling flow can be customized at a number of points:
.ds.xml configuration file is used to specify a standard
server-side connector to service your requests.
OperationBinding allow you to modify the dataSource request
dynamically at transaction-processing time, using built-in
Chaining to dynamically set data values according to the results of earlier
DataSourceField.validators defined in
.ds.xml file will be processed on both the client and the server. In
addition to the built-in validator types, entirely custom server validation logic may be
SQL Templating to change, add to or even completely replace the SQL sent to the
database, including calling stored procedures
allows you to specify an explicit custom DataSource subclass to create as your DataSource
instance. This must be a subclass of
IDACall servlet, they will be passed to
standard methods on this DataSource, which can be overridden for custom behavior.
execute(), method which can be overridden directly, or
developers may override the operation-specific methods
called from the standard
SQLDataSource, or create an entirely custom implementation
Invocation to call directly into your own Java classes. An operation configured to use
DMI will invoke the specified method instead of running through the standard DataSource
execute() method directly - the DMI implementation can then use
dsRequest.execute() to call the default behavior. This means DMIs allow you
to modify the
DSRequest before it executes, modify the
DSResponse before it returns, or replace the default behavior with unrelated
actions. Note that DMI can be applied
to all operations, or to
individual operation bindings,
and can be used in conjunction with a
server scripting to add small amounts of business logic
right in your
.ds.xml file (either
per operation, or as standard
DMI scripts allow you to add business logic just like normal DMIs, but don't require the
logic to be in a separate .java file.
RPCManager.processRequest() within your Spring Controller or
whatever the equivalent is in the framework in use.
However, note carefully that taking
this approach is often a sign that the Smart GWT architecture has not been correctly
understood. Smart GWT is architected for client-server data communication, as
opposed to early web MVC frameworks which do everything on the server. In particular, it is
absolutely incorrect to represent every individual DataSource operation - or even every
DataSource - as a separate Spring Controller because this implies different URLs for different
operations. All DataSource operations should go through a single URL in order to allow
transaction queuing - see these @see Queuing examples.
Note that, as you continue to integrate your prototype
with your backend, you can use a mixture of DataSources that have been fully integrated with
your backend and DataSources that are running in "client-only" mode (see
Important methods for handling DataSource requests
The basic flow of logic for handling DataSource requests is:
|1. Determine operation type (Fetch, Add,
Update, Remove) for a single request. Not necessary if you follow the recommendations for
writing a custom DataSource and provide
your implementation via
executeFetch(), executeAdd(), et al.
|2. Get inbound values (Add, Update) and/or criteria (Fetch, Update, Remove) for this request.
|3. Business logic, validation, calls to data and service tiers... anything you can code.
|execute custom logic
|4. Set status and data for the response.