Index: openacs-4/packages/acs-core-docs/www/object-system-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/object-system-design.html,v diff -u -N -r1.29.2.1 -r1.29.2.2 --- openacs-4/packages/acs-core-docs/www/object-system-design.html 10 Jun 2009 22:24:08 -0000 1.29.2.1 +++ openacs-4/packages/acs-core-docs/www/object-system-design.html 6 Jul 2009 11:14:28 -0000 1.29.2.2 @@ -33,7 +33,7 @@ object type (e.g. users) to instances of another object type (e.g. groups).

The next section will explore these facilities in the context of the the -particular programming idioms that we wish to generalize.

Related Links

This design document should be read along with the design documents for the new groups system, subsites and the permissions system

History

The motivation for most of the facilities in the OpenACS 4 Object Model can be +particular programming idioms that we wish to generalize.

Related Links

This design document should be read along with the design documents for the new groups system, subsites and the permissions system

History

The motivation for most of the facilities in the OpenACS 4 Object Model can be understood in the context of the 3.x code base and the kinds of programming idioms that evolved there. These are listed and discussed below.

Object Identification

Object identification is a central mechanism in OpenACS 4. Every application object in OpenACS 4 has a unique ID which is mapped to a row in a central table @@ -102,7 +102,7 @@ permission to perform action Y on object Z.

The context system forms the basis for the rest of the OpenACS access control system, which is described in in two separate documents: one for the permissions system and another for the party groups system. The context system -is also used to implement subsites.

Object Types

As mentioned above, many OpenACS modules provide extensible data models, and +is also used to implement subsites.

Object Types

As mentioned above, many OpenACS modules provide extensible data models, and need to use application specific mechanisms to keep track of user defined attributes and to map application data to these attributes. In the past, modules either used user/groups or their own ad hoc data model to provide @@ -445,7 +445,7 @@ the knowledge level data model to create, manage, query and manipulate objects in a uniform manner. The acs_rels table has an analogous role in storing information on relations.

These are all the tables that we'll discuss in this document. The rest -of the Kernel data model is described in the documents for subsites, the permissions system and for the groups system.

Some examples of how these tables are used in the system can be found in +of the Kernel data model is described in the documents for subsites, the permissions system and for the groups system.

Some examples of how these tables are used in the system can be found in the discussion of the API, which comes next.

API

Now we'll examine each piece of the API in detail. Bear in mind that the Object Model API is defined primarily through PL/SQL packages.

Object Types and Attributes

The object system provides an API for creating new object types and then attaching attributes to them. The procedures create_type and