helma.org/wiki/Workspace/philmaker/HopObjects Explained

Version 41

philmaker — Thu, 22 Nov 2007 07:39:09 +0000

7	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. If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.
13
14	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.
15

Version 40

philmaker — Thu, 22 Nov 2007 07:37:47 +0000

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* HopObjectsHopObject branches. The first HopObject branch will be automatically created according the folder in your apprepresent 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. If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.

Version 39

philmaker — Thu, 22 Nov 2007 07:36:01 +0000

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 HobObject 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.

Version 38

philmaker — Thu, 22 Nov 2007 07:35:16 +0000

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 respresents 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)

Version 37

philmaker — Thu, 22 Nov 2007 07:34:42 +0000

In Helma, a HopObject is a base object which 1. can contain child HopObjects 2. serves url 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 respresents 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)

Version 36

philmaker — Thu, 22 Nov 2007 07:34:26 +0000

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 respresents 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)

Version 35

philmaker — Thu, 22 Nov 2007 07:33:46 +0000

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 Root HopObject which is 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 respresents 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)

Version 34

philmaker — Thu, 22 Nov 2007 07:33:33 +0000

In Helma, a HopObject is a base object which accepts children and 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 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 respresents 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)

Version 33

philmaker — Thu, 22 Nov 2007 06:29:41 +0000

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* HopObjects. The first HopObject will be automatically created according the folder in your app. A second HopObject 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. If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.

Version 32

philmaker — Wed, 21 Nov 2007 22:22:33 +0000

In Helma, a HopObject is a base object which accepts children and can also persist to XML or a database. Each Helma app has a root HopObject which is 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 respresents the previous token in the URL. Example: a. (root)/hop1/hop2/action calls hop2Hop2.action.hac - b. (root)/hop1/hop2 calls hop2Hop2.main.hachac (uses main.hac by convention)

Version 31

philmaker — Wed, 21 Nov 2007 22:21:53 +0000

In Helma, a HopObject is a base object which accepts children and can also persist to XML or a database. Each Helma app has a root HopObject which is 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 respresents the previous token in the URL. Example: (root)/hop1/hop2/actiona. (root)/hop1/hop2/action calls hop2.action.hac - b. (root)/hop1/hop2 calls hop2.main.hac

Version 30

philmaker — Wed, 21 Nov 2007 22:19:51 +0000

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* HopObjects. The first HopObject will be automatically created according the folder in your app. A second HopObject 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. 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. If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.

Version 29

philmaker — Wed, 21 Nov 2007 22:19:17 +0000

Version 28

philmaker — Wed, 21 Nov 2007 07:23:31 +0000

This nature of HopObjects can be a little confusing if you are trying to develop a traditional webapp. For a traditional webapp, you will likely use two *separate* HopObjects. The first HopObject will be automatically created according the folder in your app. A second HopObject you will use for data persistance 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. 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. If you edit the values of a HopObject which is already attached to the root chain, you must manually call persist() on that HopObject.

Version 27

philmaker — Wed, 21 Nov 2007 07:22:49 +0000

10	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?info? OMG, that would be so cool.

Version 26

philmaker — Wed, 21 Nov 2007 07:21:52 +0000

10	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?

Version 25

philmaker — Wed, 21 Nov 2007 07:20:55 +0000

10	Is the user user/users HopObject chain accessible via URL? If so I don't understand how it all relates/resolvesrelates/resolves to any HopObjects connected directly to root.

Version 24

philmaker — Wed, 21 Nov 2007 07:18:26 +0000

6
7	Note: is it possible to configure Helma such that these two urls return the same pages?
8	a. http://dev.helma.org/config/users/philmaker/first/second/
9	b. http://dev.helma.org/first/second/
10	Is the user HopObject chain accessible via URL? If so I don't understand how it all relates/resolves.
11
12

Version 23

philmaker — Wed, 21 Nov 2007 07:11:32 +0000

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 scheme but also persist application data. For instance, with a wiki, a HobObject 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.

Version 22

philmaker — Wed, 21 Nov 2007 07:10:43 +0000

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 webblogweblog. 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 URL scheme but also persist application data. For instance, with a wiki, a HobObject 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.

Version 21

philmaker — Tue, 20 Nov 2007 03:39:23 +0000

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 webblog. 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 URL scheme but also persist application data. For instance, with a wiki, a HobObject 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.