Helma Logo
main list history
previous version  overview  next version

Version 11 by hannes on 12. August 2006, 01:55

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|JavaScript Inheritance Sugar*:

  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");

== Host Objects ==

=== req ===

Implemented *in Helma core|Source/helma/trunk/src/org/helma/web/ScriptableRequest.java* with additional features and properties, fully scriptable through Request.prototype.

=== res ===

Implemented *in Helma core|Source/helma/trunk/src/org/helma/web/ScriptableResponse.java* 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 ===

To be determinedLooks like Helma 1 path object, depends a lot on but additionally contains hooks for performing *request path mapping* implementationmapping*. 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.