Index: openacs-4/packages/acs-content-repository/www/doc/tutorial.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-content-repository/www/doc/tutorial.adp,v diff -u -r1.2.2.2 -r1.2.2.3 --- openacs-4/packages/acs-content-repository/www/doc/tutorial.adp 9 Jun 2016 08:44:49 -0000 1.2.2.2 +++ openacs-4/packages/acs-content-repository/www/doc/tutorial.adp 9 Jun 2016 13:03:11 -0000 1.2.2.3 @@ -43,15 +43,15 @@ various information associated with it, such as deadlines, descriptions of what needs to be accomplished, and so on:

-Task
+Task
           Title
           Description
           Task Number
         
 

Overview

First of all, let's get some terminology out of the way. Columns -of a table are referred to as attributes in content +of a table are referred to as attributes in content repository-speak.

The steps to set up your data model are as follows: @@ -76,10 +76,10 @@

You will have two tables: one with versioned attributes, and one without versioned attributes.

-Convention: often, developers will name the first table -by what it is (in my case pm_tasks), and the second, +Convention: often, developers will name the first table +by what it is (in my case pm_tasks), and the second, versioned table by the same name, but with _revisions at the end. -Thus, I'll name my second table pm_tasks_revisions.

+Thus, I'll name my second table pm_tasks_revisions.

This is actually very easy:

Versioned portion:

@@ -90,7 +90,7 @@ constraint pm_tasks_revisions_id_pk primary key constraint pm_tasks_revisions_id_fk - references cr_revisions(revision_id) + references cr_revisions(revision_id) on delete cascade, title varchar(100), @@ -107,7 +107,7 @@ constraint pm_tasks_id_pk primary key constraint pm_tasks_id_fk - references cr_items(item_id) + references cr_items(item_id) on delete cascade, task_number integer @@ -125,9 +125,9 @@ were warned.

Notice that each table uses as its primary key a reference to either the cr_revisions table or the -cr_items table. A content item is basically -just some content: either text or binary data. The contents -revisions table keeps track of which version from the +cr_items table. A content item is basically +just some content: either text or binary data. The contents +revisions table keeps track of which version from the tasks_revisions table is the most current, and which one is live.

All this is going inside the @@ -155,8 +155,8 @@

You then need to add in all the attributes, so that the content repository can do some magic things behind the scenes. The content -repository doesn't know about what's inside of the pm_tasks -and pm_tasks_revisions tables, so we teach it:

+repository doesn't know about what's inside of the pm_tasks +and pm_tasks_revisions tables, so we teach it:

           -- add in attributes
           
@@ -195,7 +195,7 @@
         
 

-Side effect: once you've created the content type, the +Side effect: once you've created the content type, the content repository creates a view for you called pm_tasks_revisionsx. Note the x at the end of the name. If you're using Postgres, I believe it will also create a @@ -218,12 +218,12 @@ Another nice thing is that all that messy business of defining your attributes through the API is taken care of.

-Types is the content repository are another term for +Types is the content repository are another term for tables, although that doesn't explain it completely. Types are also kept track of within OpenACS, in the acs_object_types table, so the system knows about the tables you create, and can do some intelligent things with them.

-

A lot of the intelligent things you can do with this +

A lot of the intelligent things you can do with this information is still being built. But imagine for example that you are using the project manager package I've written. You work at an ice cream company, and every task that is done also has an @@ -316,12 +316,12 @@ pm_tasks_revisions, and some additional information like who entered the information is stored in cr_revisions and cr_items. Whenever you make a change to this item, you don't change the table -yourself, but add +yourself, but add a revision, using your pm_task__new_task_revision function (which we'll write in a little bit). This function adds another revision, but -not +not another item or cr_item. After you've added another revision, you'll have two revisions and one item. Two entries in cr_revisions (and pm_tasks_revisions), and one item in cr_items and @@ -509,25 +509,25 @@ cr_items:

-item_id - unique id for this item, will be -different than the revision_id
parent_id - used to group items into a hierarchy (see -below)
name - this is used to make a URL by the content repository. +item_id - unique id for this item, will be +different than the revision_id
parent_id - used to group items into a hierarchy (see +below)
name - this is used to make a URL by the content repository. It must be unique per content folder. You can use a number, or something like project_231. One way to do this is to set it equal -to a title plus the item_id.
locale - not sure, probably for internationalization -support
live_revision - this is equal to the cr_revision table's -revision_id that is the live version
latest_revision - this is equal to the cr_revision table's -revision_id that is the latest version
publish_status - not sure
content_type - not sure
storage_type - not sure, probably text or binary?
storage_area_key - not sure
tree_sortkey - a utility column used in hierarchical +to a title plus the item_id.
locale - not sure, probably for internationalization +support
live_revision - this is equal to the cr_revision table's +revision_id that is the live version
latest_revision - this is equal to the cr_revision table's +revision_id that is the latest version
publish_status - not sure
content_type - not sure
storage_type - not sure, probably text or binary?
storage_area_key - not sure
tree_sortkey - a utility column used in hierarchical queries.
cr_revisions:
-revision_id - a unique id for this revision.
item_id - a reference to the item_id for this revision
title - you can use this for your application. For example, -My Big Project
description - you can use this for your application, as a -longer description.
publish_date - the date this was published. Not sure if this -is for your use, or internal
mime_type - the mime type.
nls_language - I believe this is for -internationalization
lob - the binary content.
content - the text content.
content_length - the length of the text or binary +revision_id - a unique id for this revision.
item_id - a reference to the item_id for this revision
title - you can use this for your application. For example, +My Big Project
description - you can use this for your application, as a +longer description.
publish_date - the date this was published. Not sure if this +is for your use, or internal
mime_type - the mime type.
nls_language - I believe this is for +internationalization
lob - the binary content.
content - the text content.
content_length - the length of the text or binary content?

Structuring your data into a hierarchy

@@ -552,7 +552,7 @@ Column | Type | Modifiers ------------------+------------------------+----------------------------- item_id | integer | not null - parent_id | integer | not null + parent_id | integer | not null name | character varying(400) | not null locale | character varying(4) | live_revision | integer | @@ -694,7 +694,7 @@ description | text | has_child_folders | boolean | default 'f' has_child_symlinks | boolean | default 'f' - package_id | integer | + package_id | integer | Note that there is a package_id