DA/.NET Client-Side Scripting

April 19, 2010 in .NET, Data Abstract, Linux, Mono, Relativity

We just finished our dataset scripting support for Data Abstract for .NET. DA now lets you define scripts on the server side (inside the schema), that the client will download and hook up to the events of the dataset. Scripting is supported for both the server and the client, and uses the RemObjects Script engine, which provides the ECMAScript (a.k.a. JavaScript) syntax.

An example, take this script for a “Customers” table:

function beforePost(row) {
  if (row["Discount"] > 50) 
    fail('Discount has to be less than 50');
  if (row["Discount"] < 0) 
    fail('Discount cannot be negative');
}
function onNewRow(row) {
  row["Discount"] = 20;
}

Now any time you fill a DataTable, on a remote data adapter with the script engine property set will receive this JavaScript from the server, and assign them to the datatable:

    var lDs := new System.Data.DataTable();
    lDs.TableName := "Customers";
    RemoteDataAdapter1.Fill(lDs, WhereExpression(nil), true);
 
    var rows := lDs.Select;
 
    rows[0].BeginEdit;
    rows[0]['Discount'] := 60;
    rows[0].EndEdit; // will fail here with a ScriptingException "Discount has to be less than 50"
 
    var lNewRec := lDs.NewRow;
    // lNewRec is preinitialized with a discount of 20 here.

Unit tests for this new feature have been written and all is working nicely. Next will be the same feature for the Linq Remote (and Local) Data Adapter.

Of course, client side scripts are there only to provide immediate user feedback, not to enforce business rules. For this reason, DA will run this business rules script not only on the client, but (where applicable) also on the server. DA also provides a range of additional server-only script events that can implement more extensive business logic – something i will talk more about, soon.

5 responses to DA/.NET Client-Side Scripting

  1. You need to have a consistent Client-Side Scripting a cross all platforms. Is RemObjects Script your new solution for that problem ?

    • The idea is that the Delphi side will also use javascript through the Microsoft Scripting Host, and the ObjC side will use javascript through the built in javascript support on Mac.

      • Hmmm, what about FreePascal/Lazarus vesrion? I think you should keep native Delphi/Lazarus nature of scripting. If JavaScript is your choice then you should implement it in Delphi/Lazarus.

        • We’ll need to see what to do about Free Pascal on non-Windows platforms. But one step at a time. It’s already a huge endeavor adding support for 3 different scripting platforms (Script/.NET. Active Script and JavaScriptCore). We’ll worry about more once we got the three core platforms covered.

  2. lDs : That’s definitly the data tables name … this is a standard:-).

    Good idea … makes sense … thank you a lot for considering this.