This tutorial covers topics which are not essential to creating a minimal working package. Each section can be used independently of all of the others; all sections assume that - you've completed the basic tutorial.
It's time to document. For the tutorial we'll use + you've completed the basic tutorial.
It's time to document. For the tutorial we'll use pre-written documentation. When creating a package from scratch, start by copying the documentation template from /var/lib/aolserver/openacs-dev/packages/acs-core-docs/xml/docs/xml/package-documentation-template.xml @@ -54,7 +54,7 @@ Writing bi01.html for bibliography Writing index.html for book [service0 xml]$
Verify that the documentation was generated and reflects - your changes by browsing to http://yoursite:8000/myfirstpackage/doc
Before you do any more work, make sure that your work is + your changes by browsing to http://yoursite:8000/myfirstpackage/doc
Before you do any more work, make sure that your work is protected by putting it all into cvs. The cvs add command is not recursive, so you'll have to traverse the directory tree manually and add as you go. (More on @@ -114,7 +114,7 @@ initial revision: 1.1 done (many lines omitted) -[service0 myfirstpackage]$
You can track comments for any ACS Object. Here we'll track +[service0 myfirstpackage]$
You can track comments for any ACS Object. Here we'll track comments for notes. On the note-edit.tcl/adp pair, which is used to display individual notes, we want to put a link to add comments at the bottom of the screen. If there are any comments, we want to @@ -135,7 +135,7 @@ there are comments. Then you pass the note id, which is also the acs_object id.
We put our two new variables in the note-edit.adp page.
<a href="@comment_add_url@">Add a comment</a> - @comments_html@
There are at least two flavors of admin user interface:
Admins use same pages as all other users, except that they are offered admin links and buttons where appropriate. @@ -212,7 +212,7 @@ <if @admin_p@ ne nil> <a href="@admin_url@">@admin_title@</a> </if> -
You can associate any ACS Object with one or more categories. In this tutorial we'll show how to equip your application with user interface to take advantage of the Categories service.
@@ -320,22 +320,22 @@ ad_script_abort }
-
There are several facilities for profiling your code in OpenACS. The first thing to do is to install the developer-support package and play around with it. But there is also support in the API for profiling your code: profiling your code using ds_profile -
Browse to the package manager. Click on tutorialapp.
Click on Generate a distribution file for this package from the filesystem.
Click on the file size (37.1KB) after the label Distribution File: and save the file to - /tmp.
The notifications package allows you to send notifications through any @@ -442,14 +442,20 @@ parameter is what appears at the end of the text returned (i.e. "... request notification</a> for pretty_name"), The url parameter should be set to the address we want the user to be redirected to after they have finished the subscription process.
This should be all you need to implement a notification system. For more examples - look at the forums package.
One of the nice things about using the OpenACS object system is that it has a built-in facility for tracking hierarchical data in an efficient way. The algorithm behind this is called - tree_sortkey.
Any time your tables are subclasses of the acs_objects + tree_sortkey.. This is built into + the PostgreSql portion of the + acs_objects table. (If you are + using Oracle, then you should just use CONNECT BY to build your + hierarchical queries, using context_id as the parent_id + column). Note that packages based on acs_objects use and/or abuse + context_id inconsistently to maintain a hierarchy.
Any time your tables are subclasses of the acs_objects table, then you automatically get the ability to structure them hierarchically. The way you do this is currently via the context_id column of