Helma 1 Compatibility Layer

The purpose of this page is to describe how all the features in Helma 1.5 will be implemented in Helma 2. Some features will be implemented in Helma core, while others will be implemented as JS libraries, extension or modules.

Code Layout Compatibility

One frequent request for Helma 2 is to make it behave and look more like ordinary JavaScript, and do less magic behind the scenes. This clashes with the desire for Helma 1 backwards compatibility. The plan is to not implement Helma 1 compatibility in Helma 2 core, but provide simple means to enable Helma 1 style code layouts from within the application.

Let's suppose the default way to define HopObject prototypes in Helma 2 uses a syntax similar to the one embraced in this experimental implementation:

  MyObject = HopObject.extend({
    foo: function() {
       ...
    },
    bar: function() {
       ...
    }
  });

Then all that is needed for using a Helma 1-like code layout is an evaluate function that understands "*" wildcards and takes an optional object to evaluate on as second argument (default is the global scope):

  // define extended HopObject prototypes/constructors
  Root = HopObject.extend();
  Weblog = HopObject.extend();
  WeblogItem = HopObject.extend();
  
  // optional: mount Helma 1.* code repository to namespace "henso"
  addRepository("/usr/local/apps/henso", "henso");
  
  // map code to HopObject prototypes
  evaluate("henso/HopObject/*", HopObject.prototype);
  evaluate("henso/Root/*", Root.prototype);
  evaluate("henso/Weblog/*", Weblog.prototype);
  evaluate("henso/WeblogItem/*", WeblogItem.prototype);

Of course this only solves the JavaScript side, but HopObject prototypes still wouldn't know about type.properties or skin files. For a complete solution, it might be simpler to provide a static HopObject method for passing repositories, or directly pass repository locations to HopObject.extend():

  Root = HopObject.extend("/usr/local/apps/henso/Root");
  Root.addRepository("/usr/local/apps/modules/fooBang");

Host Objects

req

Implemented in Helma core with additional features and properties, fully scriptable through Request.prototype.

res

Implemented in Helma core with additional features and properties, fully scriptable through Response.prototype. Currently implemented features:

• res.contentType (getter/setter)
• res.write() (multi-args)
• res.writeln() (multi-args)
• res.redirect()
• res.push()
• res.pop()

session

The Helma 2 session object has the same interface as in Helma 1, but is implemented on top of the session support in the Servlet API. Therefore, it will be possible to use all session features provided by the servlet container such as persistence and replication.

app

To be determined.

path

Looks like Helma 1 path object, but additionally contains hooks for performing request path mapping. In contrast to Helma 1, the path isn't resolved to an object array behind the scenes. Instead, it is first presented to the app in its raw, unresolved form. An app's pre-request code can convert and resolve the path to an object array if it wants to, but if and how this is done is entirely up to the application.

HopObject

Persistence Support

Implemented as Java module. For integration into Rhino see Helma 2 HopObject Implementation.

Prototype folders

May be implemented using a include(dir, prototype) feature that evaluates scripts in the given directory on the given object prototype. Thus, Helma 1 apps would require a simple js file with includes for all prototypes to run on Helma 2.

Pages linking to this page: Helma 2 alpha 1