What is it?
Why use it?
Scriplets have several major advantages over using <serverObject> to call a normal Java method.
Simplicity and Clarity
Scriptlets put business logic right next to the relevant persistence operation instead of in a separate .java file.
Faster Development Cycle
Scriptlets are compiled and executed dynamically, so you don’t need to recompile or redeploy server code to try out changes. Just edit your DataSource, then reload the page or retry the operation. Our framework will automatically detect the modified DataSource and uses the updated scriptlet. Note that scriplets are only recompiled when you change them, so they’ll only be compiled once in the final deployment of your application.
Java as a “scripting language”
The ability to use Java as a “scripting language” is particularly powerful:
- Developers do not have to know more than one language to work with the code for your application.
- Scriptlets can easily be moved into normal .java files if they are identified as reusable, become too large to manage in a .ds.xml file, or if the (small) performance boost of compiling them to .class files is desired. There is no need to translate from some other language into Java.
For these reasons we recommend using Server Scripting with Java – even for teams that would not normally consider adopting a “scripting language”.
The two primary use cases for server scripting are:
Direct Method Invocation (DMI) scriptlets are declared by adding a <script> tag to an <operationBinding> or <DataSource> tag. Like DMI logic declared via <serverObject>, DMI scriptlets can be used to add business logic by modifying the DSRequest before it is executed, modifying the default DSResponse, or taking other, unrelated actions.
Scriplet Validators are declared by adding a <serverCondition> tag to a <validator> definition. Like a validator declared via <serverObject>, a scriptlet validator defines whether data is valid by running arbitrary logic, then returning true or false.
For example, the following DMI scriptlet enforces a security constraint where all operations on the DataSource will involve the sessionId so a user can only view and modify their own records.
There is no need for a formal class or method definition even though Java is used – the context of a DMI Script is always the same, and the Server Scripting system avoids the need to add this “boilerplate code”.
For more information and examples, please download the latest Smart GWT 3.1d or SmartClient 8.3d nightly builds.
- Detailed examples for both Smart GWT and SmartClient can be found in the Examples folder under Server Examples >> Server Scripting.
- SmartClient Documentation can be found in the SmartClient Reference under Concepts >> Server Scripting.
- Smart GWT Documentation can be found in the JavaDoc under com.smartgwt.client.docs.ServerScript.
- Server Scripting will be available in Pro Edition and above for Smart GWT 3.1 and SmartClient 8.3 (coming soon).
- A Note for Smart GWT customers with 2.x Licenses: Smart GWT 3.x is a paid upgrade for Smart GWT 2.x license holders, and upgrade prices are based upon the date of your previous purchase. If you bought recently you may be eligible for a discount. Get access to the entire 3.x series by upgrading now! For a quote, please contact sales.
As always, please send us any bug reports or feedback in the Forums. Please be clear about what product and version you’re using when reporting issues.
This feature is nearly complete and can be evaluated now in our Smart GWT 3.x and SmartClient 8.x nightly builds, complete with samples and documentation. Download Smart GWT 3.x or SmartClient 8.x to get started using this new feature today!
The Isomorphic Team