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 -r1.16 -r1.16.2.1 --- openacs-4/packages/acs-core-docs/www/object-system-design.html 11 Nov 2003 10:28:27 -0000 1.16 +++ openacs-4/packages/acs-core-docs/www/object-system-design.html 21 Nov 2003 11:14:08 -0000 1.16.2.1 @@ -1,11 +1,7 @@ -
-by Pete Su,
- Michael Yoon,
- Richard Li
- and Rafael Schloming
+
By Pete Su, Michael Yoon, Richard Li, Rafael Schloming
OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff. -Presentation tools (e.g. how to display a field in a form or on a page)
All of these services involve relating additional service-related information to application data objects. Examples of application objects -include:
Bboard messages
A user home page
A ticket in the ticket tracker
In the past, developers had to use ad-hoc and inconsistent schemes to +include:
forum messages
A user home page
A ticket in the ticket tracker
In the past, developers had to use ad-hoc and inconsistent schemes to interface to various "general" services. OpenACS 4 defines a central data model that keeps track of the application objects that we wish to manage, and serves as a primary store of metadata. By @@ -83,7 +79,7 @@ that defines this table.
Until the implementation of the general permissions system, every OpenACS application had to manage access control to its data separately. Later on, a notion of "scoping" was introduced into the core data model.
"Scope" is a term best explained by example. Consider some -hypothetical rows in the address_book table:
... scope user_id group_id ... ... user 123 � ... ... group � 456 ... ... public � � ...
The first row represents an entry in User 123's personal address book, +hypothetical rows in the address_book table:
... | scope | user_id | group_id | ... |
... | user | 123 | � | ... |
... | group | � | 456 | ... |
... | public | � | � | ... |
The first row represents an entry in User 123's personal address book, the second row represents an entry in User Group 456's shared address book, and the third row represents an entry in the site's public address book.
In this way, the scoping columns identify the security context in which a @@ -94,8 +90,8 @@ abstract name for the default security domain to which the object belongs. Each context has a unique identifier, and all the contexts in a system form a tree. Often this tree will reflect an observed hierarchy in a site, e.g. a -bboard message would probably list a bboard topic as its context, and a -bboard topic might list a subsite as its context. Thus, contexts make it +forum message would probably list a forum topic as its context, and a +forum topic might list a subsite as its context. Thus, contexts make it easier to break the site up into security domains according to its natural structure. An object's context is stored in the context_id column of the acs_objects table.
We use an object's context to provide a default answer to questions @@ -858,7 +854,7 @@ procedures that allow applications to create object types, object instances, and object relations. Most of the data model is straightforward; the relation type mechanism is a bit more complex, but in return it provides functionality -on par with the old user/groups system in a more general way.
Pete Su generated this document -from material culled from other documents by Michael Yoon, Richard Li and Rafael Schloming. But, any remaining lies +on par with the old user/groups system in a more general way.
Pete Su generated this document +from material culled from other documents by Michael Yoon, Richard Li and Rafael Schloming. But, any remaining lies are his and his alone.
Prev | Home | Next |
OpenACS 4 Object Model Requirements | Up | OpenACS 4 Permissions Requirements |