Index: openacs-4/packages/acs-content-repository/www/doc/tutorial.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-content-repository/www/doc/tutorial.html,v diff -u -N -r1.2 -r1.3 --- openacs-4/packages/acs-content-repository/www/doc/tutorial.html 30 Mar 2013 20:02:44 -0000 1.2 +++ openacs-4/packages/acs-content-repository/www/doc/tutorial.html 7 Aug 2017 23:47:47 -0000 1.3 @@ -61,7 +61,7 @@ and so on:

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

+        attributes in content repository-speak. 

               
       The steps to set up your data model are as follows:
       
    
@@ -102,7 +102,7 @@
       
       
    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, versioned table by the same name, but with _revisions at the end. Thus, I'll name my second table pm_tasks_revisions. 
    
+      
    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. 
    
 
       This is actually very easy:
       
    
@@ -114,7 +114,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),
@@ -132,7 +132,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
@@ -152,9 +152,9 @@
 
       
    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. 
    
 
@@ -188,7 +188,7 @@
       
    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
+      of the pm_tasks and pm_tasks_revisions tables, so
       we teach it:
    
 
       
    @@ -231,7 +231,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
@@ -252,14 +252,14 @@
       you've added. 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
@@ -343,15 +343,15 @@
 
 
    
 
-Whenever you make a change to this item, you don't change the table 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 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 pm_tasks. 
    
+Whenever you make a change to this item, you don't change the table 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 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 pm_tasks. 
    
 
 The cr_revisions table keeps track of which item is the most recent, and which item is "live". For the edit-this-page application, for example, this is used to keep track of which revision to a page is actually being served to users. 
    
 
 In your code, you'll use your pm_tasks_revisionsx view, which joins the pm_tasks_revisions table with the cr_revisions table (and it might even join in cr_items -- I forget at the moment). 
 
 
    Defining your pl/sql functions
    
 
-You can see the actual functions used in project manager via the CVS browser's entry for project-manager. Note these are a little more expanded than what I've used in the examples above. 
+You can see the actual functions used in project manager via the GitHub browser's entry for project-manager. Note these are a little more expanded than what I've used in the examples above. 
 
 
    
 
@@ -526,31 +526,31 @@
 
 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. 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 queries. 
    
+ 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 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 content?
    
+ 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?
    
 
    
 
 
@@ -568,7 +568,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                | 
@@ -673,7 +673,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 column. The nice thing about this column is that you can use it to find the root repository, if you only have one folder per instance of your application. You can get your package_id using this call within your .tcl file:
@@ -698,10 +698,10 @@
 
 You now have a shiny new data model that handles revisions and all sorts of other things we haven't gotten to yet. Now, in your Tcl pages and your ps/sql code, you can...
 
    
-
+
    
 
    
 Get latest revision (Tcl)
-set live_revision_id [db_exec_plsql get_live_revision "select content_item__get_live_revision(:item_id)"]
+set live_revision_id [db_exec_plsql get_live_revision {select content_item__get_live_revision(:item_id)}]
 
 
    
 Get latest revision (pl/sql)