Differences between Helma 1 and Helma NG

It is quite obvious for anybody familiar with Helma 1 that NG is quite different in many fundamental ways. This article highligts some of the differences, and explains the reasoning behind these changes. I've grouped the changes into two groups: the big, obvious ones, and the smaller, not so visible ones.

Obvious Changes

More Javascript, Less Java

TODO

The Helma Shell

TODO

No HopObjects at the Core

TODO

Non-Obvious Changes

Non-accumulative Repository Chain

Like Helma 1, Helma NG is based on the concept of a list of repositories from which code and other resources are read. In fact, the repository package (contributed to Helma by Daniel Ruthardt) is one of the few larger packages of code Helma NG shares with its predecessor. However, Helma NG treats the repository path quite differently than Helma 1. Helma 1 in many cases treated the repository path in an accumulative way, meaning that things later on in the path could add to things defined in front of them. This was true for all kinds of properties files, scripts and skins. Helma NG, on the other hand, uses a more conservative approach: The first resource found in the repository path is used, and once the resource is found the search is terminated.

The reasoning behind this change is mostly to reduce complexity. Adding to one logical reource in several places can have terrible effects on clarity. By defining one thing in one place we hope to faciltate separation of concerns and improved molularity.

No need for complex URL compositing

In Helma 1, getting the URL of objects was a pretty complex task. HopObjects have a href() method to produce the correct URL, generated by walking down the parent path to collect the names of all elements in the path. Helma NG tries to avoid the need for this kind of URL generation mechanism. One important part of this is that requests are always redirected to their canonical URL. If a request resolves to an object with an implicit main action and the URL path does not end with a slash character, the request is redirected to the same URL with a trailing slash. This (simple) mechanism, which is commonly used by webservers when the URL resolves to a directory, makes sure that all relative URLs and HREFs will always be correct.

In summary, the means to create URLs and HREFs with Helma NG are:

1. Actions can find their URL by looking at the req.path property.
2. The URL for main actions always has a trailing slash, thus relative URLs will always work
3. Apps that mount other modules or apps are supposed to know their mountpoints, so linking to them is simple and can also be done using relative URLs.