|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface ServerDataIntegration
'install'
the '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 'existing metadata'
. '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
Client-side DataBoundComponent
will send DSRequest
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 'DataSource Protocol'
.
Out of the box, Smart GWT is set
up to route all DSRequests through a special servlet called IDACall
. Requests 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:com.smartgwt.client..DMI
- in other words, your code - if this is configured in the
DataSource. 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 continueexecute
method to obtain a DSResponse.This basic request handling flow can be customized at a number of points:
IDACall
servletIDACall
flow by 'writing a custom DataSource'
. This approach lets you write and maintain the minimal amount of custom code, while
taking full advantage of DataSource-agnostic features of the Smart GWT Server, like validation, queuing, transaction
chaining, support for Velocity templating, and so on.validate()
method, as described 'here'
.OperationBinding
allow you
to dynamically set data values at transaction-processing time, using built-in 'Velocity support'
execute()
method of
the DataSource to add extra processing before and/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, including calling
stored procedurescom.smartgwt.client..DMI
to call directly into your own Java classes.
As descibed in the DMI discussion linked to above, DMI calls can be used in conjunction with normal
DSRequest
process flow, thus enabling you to add custom logic to built-in DataSources without having
to create your own overridden versions of themRPCManager.processRequest()
within your Spring Controller, Struts Action, 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
Struts Action or Spring Controller, because this implies different URLs for different operations. All DataSource
operations should go through a single URL in order to allow RPCManager
- see these
${isc.DocUtils.linkForExampleId('transactionsFolder', 'Queuing examples')}.
For more information on the
DMI subsystem, see the com.smartgwt.client..DMI
class and the ${isc.DocUtils.linkForExampleId('DMI', 'DMI
example')} in the Feature Explorer.
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 ClientOnlyDataSources
).
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. |
dsRequest.getOperationType() |
2. Get inbound values (Add, Update) and/or criteria (Fetch, Update, Remove) for this request. | dsRequest.getFieldValue() dsRequest.getValues() dsRequest.getCriteria() |
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() dsResponse.setData() |
For more information, see the RPCManager
, and the ${isc.DocUtils.linkForExampleId('ormDataSource', 'Custom ORM DataSource
example')}.
DataSource.getDataFormat()
,
DataSource.getDataProtocol()
,
com.smartgwt.client.data.DataSource#getRequestProperties
,
DataSource.getServerType()
,
DataSource.getTableName()
,
DataSource.getDbName()
,
com.smartgwt.client.data.DataSource#getServerObject
,
com.smartgwt.client.data.OperationBinding#getRequestProperties
,
DSDataFormat
,
DSServerType
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |