HopObjects Explained

Version 41 by philmaker on 22. November 2007, 07:39

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 by philmaker on 22. November 2007, 07:37

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 by philmaker on 22. November 2007, 07:36

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 by philmaker on 22. November 2007, 07:35

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 by philmaker on 22. November 2007, 07:34

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 by philmaker on 22. November 2007, 07:34

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 by philmaker on 22. November 2007, 07:33

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 by philmaker on 22. November 2007, 07:33

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 by philmaker on 22. November 2007, 06:29

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 by philmaker on 21. November 2007, 22:22

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 by philmaker on 21. November 2007, 22:21

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 by philmaker on 21. November 2007, 22:19

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 by philmaker on 21. November 2007, 22:19

Version 28 by philmaker on 21. November 2007, 07:23

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 by philmaker on 21. November 2007, 07:22

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 by philmaker on 21. November 2007, 07:21

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 by philmaker on 21. November 2007, 07:20

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 by philmaker on 21. November 2007, 07:18

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 by philmaker on 21. November 2007, 07:11

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 by philmaker on 21. November 2007, 07:10

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 by philmaker on 20. November 2007, 03:39

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.

Version 20 by philmaker on 20. November 2007, 03:38

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 onon - which gets stored in the internal XML database.

Version 19 by philmaker on 20. November 2007, 03:37

Version 18 by philmaker on 20. November 2007, 03:37

HOP in HopObject stands for Helma Object Publisher (emphasis on publisher). The 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.

Version 17 by philmaker on 20. November 2007, 03:37

HOP in HopObject stands for Helma Object Publisher (emphasis on publisher). The 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 projects Gobi (wiki) and Antville (weblog) which both 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.

Version 16 by philmaker on 20. November 2007, 03:34

HOP in HopObject stands for Helma Object Publisher (emphasis on publisher). The 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 projects Gobi and AntvilleAntville which both 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.

Version 15 by philmaker on 20. November 2007, 03:34

HOP in HopObject stands for Helma Object Publisher (emphasis on publisher). The 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 projects Gobi and Antville. 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.

Version 14 by philmaker on 20. November 2007, 03:32

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 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 is connected 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 13 by philmaker on 20. November 2007, 03:31

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 HopeObject HopObject will be automatically created according the folder in your app. A second HopObject you will use for data persistance 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 is connected 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 12 by philmaker on 20. November 2007, 03:30

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

Version 11 by philmaker on 20. November 2007, 02:49

HOP in HopObject stands for Helma Object PublisherPublisher (emphasis on publisher). The design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a webblog. 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.

Version 10 by philmaker on 20. November 2007, 02:47

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 HopeObject will be automatically created according the folder in your app. A second HopObject you will use for data persistance 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 is connected 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 9 by philmaker on 20. November 2007, 02:45

HOP in HopObject stands for Helma Object Publisher. The design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a webblog. HopObjects A HopObject can have the ability to be mapped to a URL scheme and 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.

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 HopeObject will be automatically created according the folder in your app. A second HopObject you will use for data persistance 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 is connected to the root HopObject.

Version 8 by philmaker on 20. November 2007, 02:40

1	This is a private draft. Portions of thisthis are wrong and need comment.

Version 7 by philmaker on 20. November 2007, 02:01

1	This is a draft. Portions of this
5	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 HopObjectHopObjects. The firstfirst HopeObject will be automatically created according the folder in your app. A second HopObject you will use for data persistance for a user is the session...

Version 6 by philmaker on 20. November 2007, 00:35

4
5	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 HopObject. The first

Version 5 by philmaker on 19. November 2007, 22:03

HOP in HopObject stands for Helma Object Publisher. The design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a webblog. HopObjects have the ability to be mapped to a URL scheme and 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....

Version 4 by philmaker on 19. November 2007, 21:39

1	HOP in HopObject stands for Helma Object Publisher. The design of HopObjects lends itself well to sites with This is a dynamic content structure. For example, a wiki or a webblogdraft.
2
3	HOP in HopObject stands for Helma Object Publisher. The design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a webblog. HopObjects have the ability to be mapped to a URL scheme and 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

Version 3 by philmaker on 19. November 2007, 21:37

1	HOP in HopObject stands for Helma Object Publisher. The design of HopObjects lends itself well to sites with a dynamic content structure. For example, a wiki or a webblog.

Version 2 by philmaker on 19. November 2007, 21:36

1	HOP in HopObject stands for Helma Object Publisher.