Some discussion points regarding SSJS

  1. mschwartz
    mschwartz
    Three flavors of SSJS: Rhino, Spidermonkey, and soon v8.

    Namespace collisions issues abound on the server side.

    Portability is an issue. If you have to do Jaxer.db() in one environment and helma.db() in another, it could mean a bit of code to change if/when you port. This is true of just about everything you might imagine - from how to express Ext.encode() type functions might be Object.toJson(), etc.

    Integration of SSJS and something like ExtJS. Ext.data.Store and ORM on the server side could be a slick combination.

    There is no window object on the server side, nor a DOM. How best to include your scripts.

    Server side you have apache module style implementations and java servlet implementations. With one you get an application server, with the other you are in a perl or php like server environment.

    How do you deal with binary data (like images or file uploads) with a language that doesn't have a binary data type.

    And more.
  2. jay@moduscreate.com
    jay@moduscreate.com
    My first question is how does one implement a SSJS-based web service?
  3. mschwartz
    mschwartz
    It depends on the server. I'll talk about Helma here.

    Client Side
    Code:
    Ext.Ajax.request({
       method: 'POST',
       url: 'SomeService',
       params: { method: 'someFunc', arg1: someArg, echoMe: 'arbitrary text' ... },
       success: function(response) {
         var result = Ext.decode(response);
         if (result.success) {
           alert('success: ' + result.echo);
         }
         else {
           alert('failure: ' + result.message);
         }
       }
    });
    Server Side
    helma-1.6.3/apps/MyApp/Root/SomeService.js
    Code:
    (function SomeService_action() {
      function someFunc() {
        // do whatever with arg1, arg2 (they're in globals req.data.arg1, req.data.arg2, etc.)
        // let's build some example object to send back as JSON
        var result = {
          success: true,
          arg1: req.data.arg1,
          echo: req.data.echoMe
        };
        res.write(result.toJSON());
        res.stop();
      }
      if (req.data.method) {
        req.data.method();
      }
      res.write({ success: false, message: 'No such method' }.toJSON());
    })();
    Helma maps URL to URL_action()

    Thus
    /MyApp/foo => function foo_action()
    /MyApp/bar => function bar_action()
    /MyApp/SomeService => function SomeService_action()

    A bit more about helma next post.
  4. mschwartz
    mschwartz
    The global object on the client side is window. On the server, it's global. There's no document/DOM there, of course. Each server-side implementation handles the global object in its own style/paradigm.

    Since there's no DOM or document, there's no script tags to "include" your library of javascripts on the server-side. Again, each server-side implementation handles this in its own paradigm.

    Helma gives you apps/MyApp/Global where you put your javascripts you want loaded as part of the global object.

    So something like:

    apps/MyApp/Root/whatever ('n' javascripts, .js files) - these would be your _action() handlers.

    apps/MyApp/Global/whatever ('n' javascripts) - these would be in the global object of every _action() handler.

    Additionally, you can add "Modules" to the application. These can be individual files or a .zip of a bundle of files. Javascript files, that is.

    Helma does the right thing. The global object is loaded and compiled once; if you change a source on disk it is recompiled. The global object is executed (variables initialized, etc.) as you expect.

    So you can have a DB.js in Root that basically scripts Java's JDBC class to perform SQL queries, and that DB object would be globally available. And it would also use Jetty's DB connection pool, too.
  5. ethraza
    ethraza
    What about Aptana Jaxer? I remember to test it a long time ago and I was able to load ExtJs on server side and draw a Ext.window in the Dom. Of course these windows was static, and can't be moved, but the I think the Dom was there. Anyway was more than year ago, I don't remember that much and I'm writing it here more because I didn't so any comments about Jaxer in this group!
  6. mschwartz
    mschwartz
    Jaxer is my least favorite SSJS implementation. It's basically firefox running on the server. Think about how much of a load firefox is on your desktop and then think about having it try to run for 'n' users hitting your server at the same time. When I ran benchmarks against it, they were horrible.

    On the other hand, Jaxer provides some interesting capabilities, like the ability to manipulate DOM on the server before sending it to the client. So you could have some javascript that rewrites the URLs in <a href=...> tags to point at a CDN, or do other customizations on the page per user...

    It looks to me like Aptana has dropped much of its support for Jaxer and turned it into an open source only sort of project.

    John Resig wrote this blog post and some basic source code that implements enough of a DOM on the server with Rhino (the JS engine for Helma, BTW):

    http://ejohn.org/blog/bringing-the-b...to-the-server/

    It's enough to run Prototype, JQuery, Mochikit, and perhaps even ExtJS (though not mentioned).
Results 1 to 6 of 6