Helma Logo
main list history

HopObjects Explained

This is a private draft. Portions of this are wrong and need comment. I am a new Helma user.

In Helma, a HopObject is a base object which 1. can contain child HopObjects 2. serves URL requests 3. can also persist to the internal XML database or to a SQL database. Each Helma app has a Root HopObject which is the top node of a tree of HopObjects. In a Helma app, a URL request gets resolved to a path in a tree of HopObjects which are attached to the root HopObject. The exception is that the last token in the URL request is mapped to an action of HopObject which represents the previous token in the URL. Example: a. (root)/hop1/hop2/action calls Hop2.action.hac - b. (root)/hop1/hop2 calls Hop2.main.hac (uses main.hac by convention)

HopObject background: HOP in HopObject stands for Helma Object Publisher (emphasis on publisher). The multi-faceted design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a weblog. Further illustration of this are the existing projects Gobi (wiki) and Antville (weblog) which each use Helma. A HopObject can have the ability to be mapped to a token of a URL but also persist application data. For instance, with a wiki, a HopObject can pertain to the requested page portion of the URL but the HopObject can also persist the application data for that page. If I load a wiki page at /Home, a HopObject hosts that page but it also is responsible for its associated application-wide content such as the wiki page title, content, tags, and so on - which gets stored in the internal XML database.

This nature of HopObjects can be a little confusing if you are trying to develop a traditional webapp. (perhaps I mean non-RESTful here) For a traditional webapp, you will likely use two separate HopObject branches. The first HopObject branch will represent URL requests. A second HopObject branch you will use for data persistence for a user is the session.user property which itself is a HopObject. For example, when a user posts form data which is user centric, the hac action file would be responsible for copying the form values to a new HopObject which is then attached to the user HopObject. The session.user HopObject has already been connected to the root HopObject. [pending: verify this] When you attach a new HopObject to the user.session HopObject, this new HopObject is automatically persisted because it had been attached to the root HopObject.

Note: is it possible to configure Helma such that these two urls return the same pages?
a. http://dev.helma.org/config/users/philmaker/first/second/
b. http://dev.helma.org/first/second/
Is the user/users HopObject chain accessible via URL? If so I don't understand how it all relates/resolves to any HopObjects connected directly to root. Do you just have Users _extend Root via type.info? OMG, that would be so cool.

This is apparently false so ignore: If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.