Helma Logo
main list history

Version 4 by anton on 25. September 2008, 21:45

23The reasoning behind this change is mostly to reduce complexity. Adding to one logical reource resource 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.

Version 3 by hannes on 12. May 2008, 10:20

25=== Redirect to Canonical PathNo need for complex URL compositing

Version 2 by hannes on 12. May 2008, 10:20

25=== Redirect to Canonical Path
27In 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.
28
29In summary, the means to create URLs and HREFs with Helma NG are:
30
31# Actions can find their URL by looking at the req.path property.
32# The URL for main actions always has a trailing slash, thus relative URLs will always work
33# 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.

Version 1 by hannes on 11. May 2008, 21:10

1It 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.
2
3= Obvious Changes
4
5=== More Javascript, Less Java
6
7TODO
8
9=== The Helma Shell
10
11TODO
12
13=== No HopObjects at the Core
14
15TODO
16
17= Non-Obvious Changes
18
19=== Non-accumulative Repository Chain
20
21Like 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.
22
23The 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.
24