Re: How to use JavaScript to customize both the client and server in a consistent way?

It's true that I can hand-write these explicit bindings for client and server, and if I can manage to unit test it, it might not be too hard to maintain, but the writing of these bindings is what I wanted to avoid. It's looking more and more like I can't avoid it.

For security, I embedded Rhino on the server and implemented a ClassShutter (http://blog.notdot.net/2009/10/Server-side-JavaScript-with-Rhino) to restrict all classes except java.lang, and may add a few others. I'm not yet 100% convinced that this is enough.

I still would _really_ like this to work client-side, if possible, because while getPrice could be a server call, I have cases where I'd like to call the customer's script repeatedly to test for something across multiple dates, for example, which would mean many round-trip calls. Yes, I could architect the call to call the server only once, but so far doing this client-side still seems the easiest and lowest latency way, if it's possible.

In my case, getSomethingUseful is just a placeholder for many methods. I've got a number of custom methods on my own BasicDate class I've written, for example (because I need a consistent date class between the client and server, and since there is no java.util.Calendar on the client side, and the Date methods are deprecated, using those is too risky.) I would rather they just be able to call into the classes that I allow them to.

I like Groovy, and wish it could be made to work client side. I'm going to try this custom glue / explicit bindings approach with JavaScript, and if I get lost in the woods, I might end up right where you are! Thanks for your response.

On Monday, May 12, 2014 11:29:29 PM UTC+2, Ignacio Baca Moreno-Torres wrote:

If you only one to expose the JS code to do expressions, you can define a concrete and reduced context where the expression will be executed. For example, if you want to evaluate the price, just add all the properties you may need (probably all properties of the item bean) to the script execution bindings. The creation of this bindings may not be shared between client and server, but it's not complicated. Access random internal classes like MyClass::getSomethingUseful it's a bad idea, it's better to expose explicit binding, so if you want to expose MyClass::getSomethigUseful you may add a util object with a getSomethigUseful method, this is safer, and also solves your client/server problem. Although, the process to add this methods to the context may also be a little different between client and server.

This reduced context also is a good idea to reduce your second big problem, the security! Execute dangerous code through this script it's very easy, and restrict the access it's difficult. There are a lot of articles and discussions like http://stackoverflow.com/questions/1399505/sandboxing-jsr-223. I try to do something similar, but I end up using Groovy (only server) because this utility http://groovy.codehaus.org/api/org/codehaus/groovy/control/customizers/SecureASTCustomizer.html 'solves' the security problem.

On Saturday, May 10, 2014 4:29:56 PM UTC+2, Phineas Gage wrote:

I am writing a GWT app that will be usable by multiple customers. I'd like for my customers to be able to customize the app, both on the server side and client side by writing JavaScript. In other words, they could do things like:

- Set some configuration for their site, like its name, their web site URL, address, items on their site, etc.

- Write a JavaScript function to, for example, calculate the price for some item based on its properties. So the price calculation could be done on both the client and server, and no recompiling would be needed to change the price calculation.

The beauty of this is that they could write the JavaScript, and it could be run using JSNI on the client and Rhino on the server, giving consistent results. This could also get me out of the business of writing a bunch of administrative UI code to handle the many possibilities for customization that customers would want, and also give them much more flexibility, particularly for price calculations, where the customers want endless flexibility, and writing a rules engine to handle all of those cases would be very complicated.

Obviously, the JavaScript they write has to be runnable on both the client and server. And, if it's just a matter of returning primitives or the customer writing functions that take and return primitives, it's easy. Simple JavaScript code snippets like this:

var myname='Joe';

function getMyName() { return 'Joe' };

can be syntactically the same for both JSNI and Rhino.

But the fun soon ends. Let's say I want to allow them to call into methods in Java classes that I've defined, so I can give them an API to do useful things. The syntax for accessing Java objects from JavaScript is vastly different between Rhino and JSNI:

// Rhino
com.abc.package.MyClass.getSomethingUseful();

// JSNI: first in Java
public static native String exportGetSomethingUseful() /*-{
   getSomethingUseful = $entry(@com.abc.package.MyClass::getSomethingUseful());
}-*/;

// JSNI: then in JavaScript
getSomethingUseful();

The situation gets more challenging if you want to pass instances of your own Java classes into JavaScript for their use, or call from JavaScript into APIs defined in Java. You've got to define host objects in Rhino, and I'm not even sure how you do it in JSNI without writing glue code by hand so that they wouldn't have to learn JSNI's arcane syntax,

My question is: I don't think it's possible for the JavaScript syntax to be the same between JSNI and Rhino without writing some glue code on both the client and server in JavaScript to insulate them from these syntactical differences when working with APIs defined in Java. Am I right, or have I missed anything?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.