public interface ServerDataIntegration
Smart GWT Java Server Frameworkinto any J2SE/J2EE environment, including any existing web application
create DataSourcesvia an XML declaration, possibly on-the-fly from
Client-side Data Integrationin 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:
RPCManagerto manage the processing of the entire queue of transactions. For every DSRequest in the queue, this RPCManager:
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
executemethod to obtain a DSResponse.
This basic request handling flow can be customized at a number of points:
DataSource.serverTypespecification within your
.ds.xmlconfiguration file is used to specify a standard server-side connector to service your requests.
OperationBindingallow you to modify the dataSource request dynamically at transaction-processing time, using built-in
Transaction Chainingto dynamically set data values according to the results of earlier transactions.
DataSourceField.validatorsdefined in the
.ds.xmlfile 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 implemented using
"serverCustom" type validators.
SQL Templatingto change, add to or even completely replace the SQL sent to the database, including calling stored procedures
DataSource.serverConstructorallows you to specify an explicit custom DataSource subclass to create as your DataSource instance. This must be a subclass of
IDACallservlet, 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
executeRemove()called from the standard
SQLDataSource, or create an entirely custom implementation from scratch.
custom server dataSource overview
Direct Method Invocationto 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
DSRequestbefore it executes, modify the
DSResponsebefore 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 scriptingto add small amounts of business logic right in your
per operation, or as standard handling for
all operations). 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
|2. Get inbound values (Add, Update) and/or criteria (Fetch, Update, Remove) for this request.||dsRequest.getFieldValue() |
|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.||dsResponse.setStatus() |