| Prev | Chapter 6. OpenACS Developer's Guide | Next |
|---|
+
+Developing data models in OpenACS 5.0.0 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,7 +27,7 @@
Thinking further ahead, we can imagine doing any of the following things with Notes as well: -
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.
+
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 @@ -54,7 +54,7 @@ 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."
-
Using ACS objects is straightforward: all that's required are a few extra steps in the design of your application data model.
@@ -80,8 +80,8 @@
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: -
+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 @@ -141,7 +141,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 @@ -166,7 +166,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: @@ -214,7 +214,7 @@ 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. -
While it is hard to give general design advice without knowing anything about a particular application, you should follow the following rule of thumb when deciding when to hook part of your data @@ -312,12 +312,12 @@ kind of design decision is mostly made on an application-by-application basis, but this is a good baseline from which to start. -
In this section we cover some overall guidelines for designing data models that are meant to be integrated with the OpenACS object system.
-There are two basic rules you should follow when designing OpenACS 4.6 data +There are two basic rules you should follow when designing OpenACS 5.0.0 data models: @@ -371,29 +371,29 @@ when to use inherited attributes is fairly straightforward, but requires a good amount of thought at design time even for simple applications. -
+Hooking into the OpenACS 5.0.0 object system brings the application developer numerous benefits, and doing it involves only four easy steps: -
+
Describe the a new object type to the system. Most new application types will be subtypes of the built-in type acs_object. -
+
Define a table to store application object data. -
+
Define a PL/SQL package to store procedures related to the new type. You have to define at least a function called new to create new application objects and a procedure called delete to delete them. -
+
Define a package body that contains the implementations of the PL/SQL procedures defined above. -
+
Try not to write queries in your application that join against acs_objects. This means you should never use the fields in acs_objects for application-specific purposes. This is especially true for the context_id field.
-