| Prev | Chapter�11.�Development Reference | Next |
|---|
By Pete Su
+ +-Developing data models in OpenACS 5.2.0d1 is much like developing data models +Developing data models in OpenACS 5.2.3b1 is much like developing data models for OpenACS 3, save for the implementation. As usual, you need to examine how to model the information that the application must store and manipulate, and define a suitable set of SQL tables. In our Notes @@ -27,8 +28,8 @@
Define access control policies on notes.
Attach user comments on notes.
Allow users to define custom fields to store on their notes.
Automatically generate input forms or output displays for notes.
Allow other applications to use notes in ways we don't know of yet.
In OpenACS, the key to enabling these types of services on your application data is to take advantage of the Object System. The first -question, then, is "Just what are objects, and what do -you use them for anyway?". The short answer: objects are anything +question, then, is "Just what are objects, and what do +you use them for anyway?". The short answer: objects are anything represented in the application's data model that will need to be managed by any central service in OpenACS, or that may be reusable in the context of future applications. Every object in the system is @@ -46,11 +47,11 @@ in an application table, and gives you an easy way to enforce this from Tcl.
Every object has an attribute called context_id that provides a way to trivially specify both the default - permissions for an object, and the intended "scope" of an + permissions for an object, and the intended "scope" of an object. Just set the context_id to the controlling object and forget about it.
And most importantly, any future object-level service - from a general-comments replacement to personalized ranking - will - become available to your application "for free."
+ become available to your application "for free."
Using ACS objects is straightforward: all that's required are a few extra steps in the design of your application data model. @@ -78,7 +79,7 @@ Fire up your text editor and open the ROOT/packages/notes/sql/oracle/notes-create.sql (ROOT/packages/notes/sql/postgresql/notes-create.sql for the PG version) file created when we created the package. Then, do the following: -
+
First, add an entry to the acs_object_types table with the following PL/SQL call:
begin @@ -138,7 +139,7 @@ because the new type note is a subtype of acs_object, it will inherit these attributes, so there is no need for us to define them. -
The next thing we do is make a small modification to the data model to reflect the fact that each row in the notes table represents something that is not only an object of type @@ -163,7 +164,7 @@ use the acs_objects table to find objects will transparently find any objects that are instances of any subtype of acs_objects. -
The next step is to define a PL/SQL package for your new type, and write some basic procedures to create and delete objects. Here is a package definition for our new type: @@ -208,10 +209,10 @@ this way: if no permissions are explicitly attached to the object, then the object inherits its permissions from the context. For example, if I had told you how to use the permissions system to specify that an -object OBJ was "read only", then any other object that used OBJ as its -context would also be "read only" by default. We'll talk about this more +object OBJ was "read only", then any other object that used OBJ as its +context would also be "read only" by default. We'll talk about this more later. -
The PL/SQL package body contains the implementations of the procedures defined above. The only subtle thing going on here is that we must use acs_object.new to insert a row into @@ -314,7 +315,7 @@ models that are meant to be integrated with the OpenACS object system.
-There are two basic rules you should follow when designing OpenACS 5.2.0d1 data +There are two basic rules you should follow when designing OpenACS 5.2.3b1 data models: @@ -336,7 +337,7 @@ context_id to the package instance in which the note was created. The idea will be that in a real site, the administrator would create one package instance for every separate set of Notes (say, one -per user). The instance would "own" all of the notes that it created, +per user). The instance would "own" all of the notes that it created, and the administrator would be able to use the package instance as the basis for access control, which is convenient.
@@ -369,7 +370,7 @@ requires a good amount of thought at design time even for simple applications.