Interface NonJavaBackend
.NET, PHP, Serverless Integration
While Smart GWT's extensive server features are lost if you cannot install the Java-based server framework, Smart GWT UI components can be integrated with any server technology. This topic provides pointers to documentation that is most relevant for this type of integration.If you are using a non-Java backend such as PHP or .NET, you may want to consider SmartGWT's sister product SmartClient, which has the same functionality but allows programming in JavaScript instead of Java. However if you prefer to use Java on the client, this is fine - SmartGWT and Smart GWT have identical capabilities for integrating with non-Java servers.
When run on a SmartGWT project, the GWT compiler produces ordinary web assets - JavaScript files, .html files, images, etc - which can be deployed on any web server like any other web assets. How best to integrate GWT into your development workflow is outside the scope of this documentation, however, consider using the SmartGWT server-side HttpProxy (mentioned below) as a means of using a Java IDE to develop GWT Java code in the usual way, while allowing your GWT application to contact services hosted on another server (which is running your PHP, .NET or other server code). The HttpProxy can then be eliminated from your final deployment by deploying the web assets produced by GWT directly on the server running your non-Java server code.
Data Loading / Data Binding
The primary focus of
Smart GWT integration is connecting DataSource operations to your server. The Client-side Data Integration chapter covers the
key approaches, including cookbook approaches for REST-based integration with any server that
can return XML or JSON over HTTP.
Simple RPCs (non-DataSource requests)
You
can implement simple RPCs by having your server output JSON (JavaScript Object Notation) and using RPCRequest.evalResult to directly turn JSON
results into live JavaScript objects. RPCRequest.serverOutputAsString
lets you load arbitrary server results, including JSON results that need to be processed before
they can be eval()'d.
Alternatively, if you are familiar with WSDL web services, you can
implement simple RPCs as web service operations: use XMLTools.loadWSDL() to load the service definition,
and then use WebService.callOperation() to call the operations. We don't generally recommend this approach
unless you are already deeply familiar with WSDL - it's far more complicated that producing and
consuming JSON.
HTTPProxy: Cross-site or cross-port data loading
If you develop a prototype using the Smart GWT SDK and Smart GWT Java Server, and then you migrate the prototype to another server technology, you need to be aware that the Smart GWT Java Server includes an HTTPProxy servlet that allows Smart GWT interfaces to contact servers other than the origin server (bypassing what is called the "same origin policy").
Smart GWT uses the HttpProxy automatically when needed, so it may not be obvious that the HTTPProxy is in use. Then, your migrated application will encounter errors attempting to contact the HTTPProxy servlet.
To avoid these errors, ensure that all
services that your application uses are accessed using the same hostname and port as the page
was loaded from. In particular, watch for WSDL files, which contain the service URL - you may
need to use WebService.setLocation() to
ensure that the web service URL and page URL match.
If your production application really does need to access services or content hosted on other servers, typical practice is to pursue normal Smart GWT integration with your server, then write server-side code that contacts other hosts on behalf of your Smart GWT interface.