Index: openacs-4/packages/acs-core-docs/www/object-system-requirements.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/object-system-requirements.adp,v diff -u -r1.4 -r1.5 --- openacs-4/packages/acs-core-docs/www/object-system-requirements.adp 25 Apr 2018 08:38:28 -0000 1.4 +++ openacs-4/packages/acs-core-docs/www/object-system-requirements.adp 3 Sep 2024 15:37:32 -0000 1.5 @@ -1,22 +1,29 @@ -{/doc/acs-core-docs {ACS Core Documentation}} {Object Model Requirements} +{/doc/acs-core-docs/ {ACS Core Documentation}} {Object Model Requirements} Object Model Requirements +

-Object Model Requirements

<authorblurb>

By Pete Su

</authorblurb>
+Object Model Requirements
+

By Pete Su

+OpenACS docs are written by the named authors, and may be edited by +OpenACS documentation staff.

I. Introduction

A major goal in OpenACS 4 is to unify and normalize many of the core services of the system into a coherent common data model and API. In the past, these services were provided to applications in an ad-hoc and irregular fashion. Examples of such services include:

    -

  • General Comments

  • User/groups

  • Attribute storage in user/groups

  • General Permissions

  • Site wide search

  • General Auditing

    • +

  • General Comments

  • User/groups

  • Attribute storage in user/groups

  • General Permissions

  • Site-wide search

  • General Auditing

All of these services involve relating extra information and services to application data objects, examples of which include:

    @@ -71,7 +78,7 @@ for tagging application objects with unique identifiers.

    Support for Unified Access Control

    Access control should be as transparent as possible to the application developer. Until the implementation of the general -permissions system, every OpenACS application had to manage access +permission 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:

    @@ -135,9 +142,9 @@ extensively between releases or in different client installations. Furthermore, we want to avoid changes to an application's database queries in the face of any custom extensions, since such -changes are difficult or dangerous to make at runtime, and can make -updating the system difficult. Some example applications in OpenACS -3.x with modifiable data models include:

      +changes are difficult or dangerous to make at run time, and can +make updating the system difficult. Some example applications in +OpenACS 3.x with modifiable data models include:

      • User/groups: developers and users can attach custom data to group types, groups, and members of groups.

      • In the Ecommerce data model, the ec_custom_product_fields table defines attributes for catalog products, and the ec_custom_product_field_values table stores @@ -217,7 +224,7 @@ some kind of document.

      • General Permissions: Stores access control information on application data.

      • User Profiling: Maps users to pieces of content that they have looked at; content identifiers must be managed in a uniform -way.

      • Site Wide Search: Stores all content in a single flat table, +way.

      • Site-Wide Search: Stores all content in a single flat table, with object identifiers pointing to the object containing the content in the first place. This way, we can search the contents of many different types of objects in a uniform way.

        • @@ -322,10 +329,10 @@ awkward to use and limited in flexibility.

        The OpenACS 4 Object Model provides a generalized notion of scope that allows developers to represent a hierarchy of object contexts. These contexts are -used as the basis for the permissions system. In general, if an +used as the basis for the permission system. In general, if an object has no explicit permissions attached to it, then it inherits permissions from its context.

        The context data model also forms the basis of the subsites system, and is a basic part of -the permissions system, described in +the permission system, described in separate documents.

        The context data model should provide the following facilities:

        50.10 Unique ID

        Every context should have a unique ID in the system.

        50.20 Tree Structure

        The data model should support a tree structured organization of