Today we are shipping the first beta builds of RemObjects SDK and Data Abstract with our new JavaScript client support. This beta is available at beta.remobjects.com for all users with an active subscription, and we are planning to ship this feature officially in the upcoming Winter release next month.
This blog post aims at giving you a quick overview into what’s there and how to use it.
RemObjects SDK and Data Abstract for JavaScript is essentially the fourth client platform for RO/DA that we have implemented, and constitutes a fully native JavaScript implementation of our RO/DA client library – with everything you need to talk to RO or DA servers directly from JavaScript-based clients. The main focus right now is on web clients (i.e. clients running locally in a browser), but RODA/JS should also be usable from any other JavaScript based platform, such as Windows 8′s Metro, cough WebOS cough, and the like.
RODA/JS is not a separate product; rather, it ships in the box with all three of our existing server platforms: RODA/.NET, RODA/Delphi and Relativity Server.
In most cases, you will want to add the ability to expose a scripting client right from inside the regular RO/DA server you are building, and we have created components that make this really easy: Both RODA/.NET and RODA/Delphi have gained (TRO)JavaScriptHttpDispatcher and (TDA)JavaScriptHttpDispatcher components that you can simply drop into your project and hook up to your server channels. These components embed and automatically serve the core RODA/JS script files, and can also serve any custom files (scripts and HTML/CSS/Images) that you created to implement your JavaScript client (from a folder or from resources embedded in your server app).
With that done, you can simply point your browser to a subpath of your server’s URL, such as http://localhost:8099/js to access your web app.
The screenshot above shows the RO/Delphi MegaDemo, but a similar component is available for DA and on .NET, and all MegaDemos and DA Sample Servers have been extended to already expose sample JavaScript clients.
If you run the server and point your browser to it, it will look something like this (not about to win any design awards, but it works ;) ).
What does the source look like? Aside from the HTML that defines what we see, there are three script files included:
<script type="text/javascript" src="RemObjectsSDK.js"></script>
<script type="text/javascript" src="MegaDemoLibrary_intf.js"></script>
<script type="text/javascript" src="script.js"></script>
The first is the core RO/JS library – automatically served by the JavaScriptHttpDispatcher component. The second is the Interface file for our server’s RODL – more on that below. Lastly, scripts.js contains the code we custom-wrote to implement our client. Let’s look at that in more detail:
First, we create our service and related components (I’m shortening the code a bit for the purpose of this post, if you look at the real sample, you’ll see it will optionally choose between JSON and BinMessage, etc):
var Service;
createService();
function createService()
{
var svcUrl = "http://" + document.location.host + "/bin";
Service = new MegaDemoService(new RemObjects.SDK.HTTPClientChannel(svcUrl),
new RemObjects.SDK.BinMessage());
}
Next, let’s look at how we call Sum():
function BeginSumMethod()
{
var A = document.getElementById("editA").value;
var B = document.getElementById("editB").value;
Service.Sum(A, B,
function SuccessSumMethod(result)
{
AddLineToLog('Result is ' + result);
},
function ErrorSumMethod(msg, ex)
{
if (ex) {
AddLineToLog(" Error: " + ex);
} else {
AddLineToLog(msg.getErrorMessage());
});
}
As you see, JavaScript is big on asynchronicity. Instead of calling Sum() and getting back a value, Sum runs asynchronously, and we provide a callback that gets executed when the result was received (and a second callback that gets called for any errors or exceptions).
To generate Interface files for your custom RODLs (such as MegaDemoLibrary_intf.js in the sample above), both Service Builder (Windows) and rodl2objc (Mac) have been expanded with an extra option to generate .js files. Simply open your RODL and save the Intf.js, as you already know how to do for all the other languages we support:
(As you can see, rodl2objc has also received a bit of an interface facelift ;) )
That’s RemObjects SDK for JavaScript, for talking to custom Web Services. Next, let’s look at Data Abstract.
Like with RO, making a DA server accessible from JavaScript is as easy as adding the dispatcher and (optionally) some custom script or HTML files. Here’s what the JavaScript sample for our PCTrade Sample Servers looks like (both for .NET and Delphi):
On the left, there’s list of all the tables, dynamically created by looking at the schema; once a table is selected, it shows a grid on the right. For this sample, we’re using a jQuery grid, but there’s nothing that inherently ties Data Abstract to jQuery or any other JavaScript framework – you get access to the raw data via a table object and can work with it any way you please. Of course, we cannot only show data, but also maintain updates and apply them back to the server.
Let’s look at the code again:
<script src="RemObjectsSDK.js" type="text/javascript"></script>
<script src="DataAbstract.js" type="text/javascript"></script>
<script src="DataAbstract4_Intf.js" type="text/javascript"></script>
<script src="/js/jquery/jquery-1.4.4.js" type="text/javascript"></script>
<script src="/js/jquery/js/grid.locale-en.js" type="text/javascript"></script>
<script src="/js/jquery/js/jquery.jqGrid.min.js" type="text/javascript"></script>
<script src="DataAbstractjQGrid.js" type="text/javascript"></script>
In addition to the core three RO/DA files (all of which are served by default by Data Abstract’s version of the JavaScriptHttpDispatcher), we include a few jQuery files, as well as a DA-specific helper file for jQGrid that we provide for your convenience. Once again, using jQGrid is just an implementation choice for this sample (much like using QuantumGrid would be for a Delphi app).
Other than that, all the application-specific script in this sample is in the main HTML file.
For example, here is how we set up the RemoteDataAdapter:
var Channel = new RemObjects.SDK.HTTPClientChannel("http://" + window.location.host + "/JSON");
var Message = new RemObjects.SDK.JSONMessage();
var Service = new RemObjects.SDK.RemoteService(Channel, Message, "DASampleService");
var daService = new DataAbstractService(Service);
var loginService = new RemObjects.SDK.RemoteService(Channel, Message, "LoginService");
var rda = new RemObjects.DataAbstract.RemoteDataAdapter(Service, loginService, RemObjects.DataAbstract.Bin2DataStreamer);
And here is how we fetch data for a table (and show it using the jQGrid helper):
rda.getData(Tables[CurrentTable], function() {
GridView = new RemObjects.DataAbstract
.Views.JQGridView(Tables[CurrentTable], "#list", "#pager");
},
function(msg, e) {
if (e) {alert(e)}
else alert(msg.getErrorMessage());
});
If you’re familiar with RO and DA, you will already see that the classes are very similar to what you know. We have client channels, messages, remote services and a remote data adapter.
Relativity Server now also optionally exposes the required JavaScript files (including full Intf.js files for its admin API) as well as a JSON message. All you need to do to activate this is to check the Enable JavaScript Publishing option in Server Explorer:
If the option is grayed out, your Relativity Server does not support JavaScript yet; if the option is not available, you need a newer version of Server Explorer for Mac.
A Word about Cross-Domain Data Access
You might be asking: why does the JavaScript need to be served by the RO/DA server? Can’t I just put it on my website? Technically, you could, but there’s a limitation on most browsers that – for security reasons – won’t just let JavaScript connect to different servers willy-nilly. So if you’re opening a website from http://mywebsite.com, the browser won’t let the JavaScript on that site send requests to http://database.mywebsite.com:8099 – unless at least some of the scripts originate from that server. So you can embed JavaScript code in your website and have it talk to your RO/DA server on a different domain or port, but you must at least reference the RemObjectsSDK.js and/or DataAbstract.js files from the RO/DA server to let the browser know that it’s ok to connect there.
This limitation might not apply when using JavaScript on other non-web platforms, for example on Metro (we haven’t tested that yet) or application platforms such as Titanium. It’s a limitation of what the browser lets you do, not a limitation of our client library.
Summary
Our new native JavaScript client libraries open up RO and DA servers to a wide variety of new client platforms, with rich browser-based apps only being one of many possibilities.
We have a good six weeks of beta cycle left before this feature ships, and we hope you’ll give the beta builds a try and let us know any feedback you have. Head over to beta.remobjects.com now to get started.
Enjoy!
Recent Comments