Index: openacs-4/packages/acs-core-docs/www/acs-package-dev.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/acs-package-dev.html,v diff -u -r1.22 -r1.23 --- openacs-4/packages/acs-core-docs/www/acs-package-dev.html 24 Jun 2004 10:44:39 -0000 1.22 +++ openacs-4/packages/acs-core-docs/www/acs-package-dev.html 29 Jun 2004 15:50:14 -0000 1.23 @@ -1,2 +1,2 @@ Part�III.�For OpenACS Package Developers

For OpenACS Package Developers

Tutorials and reference material for creating new OpenACS packages. -

View comments on this page at openacs.org
+

Table of Contents

9. Development Tutorial
Creating an Application Package
Setting Up Database Objects
Creating Web Pages
Debugging and Automated Testing
10. Advanced Topics
Write the Requirements and Design Specs
Add the new package to CVS
Adding Comments
Admin Pages
Categories
Profile your code
Prepare the package for distribution.
Notifications
Hierarchical data
Using .vuh files for pretty urls
Laying out a page with CSS instead of tables
Sending HTML email from your application
Basic Caching
Scheduled Procedures
Future Topics
11. Development Reference
OpenACS Packages
OpenACS Data Models and the Object System
The Request Processor
The OpenACS Database Access API
Using Templates in OpenACS
Groups, Context, Permissions
Writing OpenACS Application Pages
Parties in OpenACS
OpenACS Permissions Tediously Explained
Object Identity
Programming with AOLserver
Using HTML Forms
12. Engineering Standards
OpenACS Style Guide
Release Version Numbering
Constraint naming standard
ACS File Naming and Formatting Standards
PL/SQL Standards
Variables
Automated Testing
13. Documentation Standards
OpenACS Documentation Guide
Using PSGML mode in Emacs
Using nXML mode in Emacs
Detailed Design Documentation Template
System/Application Requirements Template
14. Internationalization
Internationalization and Localization Overview
How Internationalization/Localization works in OpenACS
How to Internationalize a Package
Design Notes
Translator's Guide
D. Using CVS with an OpenACS Site
View comments on this page at openacs.org
Index: openacs-4/packages/acs-core-docs/www/cvs-tips.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/cvs-tips.html,v diff -u -r1.23 -r1.24 --- openacs-4/packages/acs-core-docs/www/cvs-tips.html 24 Jun 2004 10:44:39 -0000 1.23 +++ openacs-4/packages/acs-core-docs/www/cvs-tips.html 29 Jun 2004 15:50:14 -0000 1.24 @@ -1,7 +1,7 @@ Appendix�D.�Using CVS with an OpenACS Site

Appendix�D.�Using CVS with an OpenACS Site

By Joel Aufrecht

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff. -

Add the Service to CVS - OPTIONAL.�These steps take an existing OpenACS directory and add +

Add the Service to CVS - OPTIONAL.�These steps take an existing OpenACS directory and add it to a CVS repository.

  1. Create and set permissions on a subdirectory in the local cvs repository.

    [root root]# mkdir /cvsroot/$OPENACS_SERVICE_NAME
     [root root]# chown $OPENACS_SERVICE_NAME.$OPENACS_SERVICE_NAME /cvsroot/$OPENACS_SERVICE_NAME
    Index: openacs-4/packages/acs-core-docs/www/docbook-primer.html
    ===================================================================
    RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/docbook-primer.html,v
    diff -u -r1.40 -r1.41
    --- openacs-4/packages/acs-core-docs/www/docbook-primer.html	24 Jun 2004 10:44:39 -0000	1.40
    +++ openacs-4/packages/acs-core-docs/www/docbook-primer.html	29 Jun 2004 15:50:15 -0000	1.41
    @@ -36,7 +36,7 @@
           In order to separate content and presentation, all OpenACS documentation will be marked up to conform to the 
           DocBook XML DTD 
           
    -      
    +      
           This enables us to publish in a variety
           of formats and relieves each contributor of the burden of  presentation, freeing him to focus
           on content and sharing knowledge.
    @@ -57,7 +57,7 @@
     	list of elements and use more exotic features in your
           documents. The list is made up of SGML-elements but basically
           the same elements are valid in the XML DTD as long as you remember to:
    -      
    +      
         

    • Always close your tags with corresponding end-tags and to not use other tag minimization @@ -106,7 +106,7 @@ The documentation for each package will make up a little "book" that is structured like this - examples are emphasized: - +

           book                        : Docs for one package - templating
      @@ -130,20 +130,20 @@
             sources of these DocBook documents
             to get an idea of how they are tied together.
           

    Headlines, Sections

    - + Given that your job starts at the sect1-level, all your documents should open with a <sect1>-tag and end with the corresponding </sect1>.

    - + You need to feed every <sect1> two attributes. The first attribute, id, is standard and can be used with all elements. It comes in very handy when interlinking between documents (more about this when talking about links in the section called “Links”). The value of id has to be unique throughout the book you're making since the id's in your sect1's will turn into filenames when the book is parsed into HTML.

    - + The other attribute is xreflabel. The value of this is the text that will appear as the link when referring to this sect1.

    @@ -158,7 +158,7 @@ </sect1>

    - + Inside this container your document will be split up into <sect2>'s, each with the same requirements - id and xreflabel @@ -167,7 +167,7 @@ When it comes to naming your sect2's and below, prefix them with some abbreviation of the id in the sect1 such as requirements-overview.

Code

- + For displaying a snippet of code, a filename or anything else you just want to appear as a part of a sentence, we will use the tag <computeroutput>. @@ -177,12 +177,12 @@ <programlisting> is used. Just wrap your code block in it; mono-spacing, indents and all that stuff is taken care of automatically.

Links

- + Linking falls into two different categories: inside the book you're making and outside:

1. Inside linking, cross-referencing other parts of your book

By having unique id's you can cross-reference any part of your book with a simple tag, regardless of where that part is. -

Check out how I link to a subsection of the Developer's Guide:

Put this in your XML:

+	  

Check out how I link to a subsection of the Developer's Guide:

Put this in your XML:

 - Find information about creating a package in
 <xref linkend="packages-making-a-package"></xref>.
 

And the output is:

@@ -206,7 +206,7 @@
 	    packages-looks, the
 	    parser will try its best to explain where the link takes you.
 	  

2. Linking outside the documentation

- + If you're hyper-linking out of the documentation, it works almost the same way as HTML - the tag is just a little different @@ -227,7 +227,7 @@ do it, so if you want to start converting your documents right away, start out with the ones without graphics ;)

- + To insert a graphic we use the elements <mediaobject>, <imageobject>, @@ -253,7 +253,7 @@ Put your graphics in a separate directory ("images") and link to them only with relative paths.

Lists

- + Here's how you make the DocBook equivalent of the three usual HTML-lists:

1. How to make an <ul>

Making an unordered list is pretty much like doing the same thing in HTML - if you close your <li>, that is. The only differences are that each list item has to be wrapped in something more, such as @@ -298,7 +298,7 @@ </variablelist>

Tables

- + DocBook supports several types of tables, but in most cases, the <informaltable> is enough: @@ -335,7 +335,7 @@ <table> for an example.

Emphasis

- + Our documentation uses two flavors of emphasis - italics and bold type. DocBook uses one - <emphasis>.

Index: openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html,v diff -u -r1.39 -r1.40 --- openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html 24 Jun 2004 10:44:39 -0000 1.39 +++ openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html 29 Jun 2004 15:50:15 -0000 1.40 @@ -59,7 +59,7 @@

Transition Rules

So what distinguishes an alpha release from a beta release? Or from a production release? We follow a specific set of rules for how OpenACS makes the transition from one state of maturity to -the next. These rules are fine-tuned with each release; an example is 5.0.0 Milestones and Milestone Criteria

Naming Database Upgrade Scripts

Database upgrade scripts must be named very precisely in order for the Package Manager to run the correct script at the correct time.

  1. Upgrade scripts should be named /packages/myfirstpackage/sql/postgresql/upgrade/upgrade-OLDVERSION-NEWVERSION.sql

  2. If the version you are working on is a later version than the current released version, OLDVERSION should be the current version. The current version is package version in the APM and in /packages/myfirstpackage/myfirstpackage.info. So if forums is at 2.0.1, OLDVERSION should be 2.0.1d1. Note that this means that new version development that includes an upgrade must start at d2, not d1. +the next. These rules are fine-tuned with each release; an example is 5.0.0 Milestones and Milestone Criteria

Naming Database Upgrade Scripts

Database upgrade scripts must be named very precisely in order for the Package Manager to run the correct script at the correct time.

  1. Upgrade scripts should be named /packages/myfirstpackage/sql/postgresql/upgrade/upgrade-OLDVERSION-NEWVERSION.sql

  2. If the version you are working on is a later version than the current released version, OLDVERSION should be the current version. The current version is package version in the APM and in /packages/myfirstpackage/myfirstpackage.info. So if forums is at 2.0.1, OLDVERSION should be 2.0.1d1. Note that this means that new version development that includes an upgrade must start at d2, not d1.

  3. If you are working on a pre-release version of a package, use the current package version as OLDVERSION. Increment the package version as appropriate (see above) and use the new version as NEWVERSION. For example, if you are working on 2.0.1d3, make it 2.0.1d4 and use upgrade-2.0.1d3-2.0.1d4.sql.

  4. Database upgrades should be confined to development releases, not alpha or beta releases.

  5. Never use a final release number as a NEWVERSION. If you do, then it is impossible to add any more database upgrades without incrementing the overall package version.

  6. Use only the d, a, and b letters in OLDVERSION and NEWVERSION. rc is not supported by OpenACS APM.

  7. The distance from OLDVERSION to NEWVERSION should never span a release. For example if we had a bug fix in acs-kernel on 5.1.0 you wouldn't want a file upgrade-5.0.4-5.1.0d1.sql since if you subsequently need to provide a 5.0.4-5.0.5 upgrade you will have to rename the 5.0.4-5.1.0 upgrade since you can't have upgrades which overlap like that. Instead, use upgrade-5.1.0d1-5.1.0d2.sql Index: openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html,v diff -u -r1.28 -r1.29 --- openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 24 Jun 2004 10:44:39 -0000 1.28 +++ openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 29 Jun 2004 15:50:15 -0000 1.29 @@ -1,4 +1,4 @@ -External Authentication Requirements

    External Authentication Requirements

    Vision

    People have plenty of usernames and passwords already, we +External Authentication Requirements

    External Authentication Requirements

    Vision

    People have plenty of usernames and passwords already, we don't want them to have yet another. We want people to be able to log in to OpenACS with the same password they use to log in to any other system.

    Besides, administrators have better things to do than create @@ -44,7 +44,7 @@ only one implementation of the authentication API, namly the one included in OpenACS Core.

  8. Authentication Driver API: The service contract which authentication drivers implement.

Conceptual Pictures

Authentication:

-

Account Management (NO PICTURE YET)

Batch Synchronization (NO PICTURE YET)

Requirements

New API

FeatureStatusDescription
EXT-AUTH-01AExtend Authentication/Acct Status API
EXT-AUTH-03AAccount Creation API
EXT-AUTH-05APassword Management API
EXT-AUTH-30AAuthority Management API

Login

FeatureStatusDescription
EXT-AUTH-04ARewrite login, register, and admin pages to use APIs
EXT-AUTH-38Aad_form complain feature
EXT-AUTH-19ARewrite password recovery to use API
EXT-AUTH-21ARewrite email verification with API
EXT-AUTH-28AUsername is email switch

Users will log in using a username, a authority, and a +

Account Management (NO PICTURE YET)

Batch Synchronization (NO PICTURE YET)

Requirements

New API

FeatureStatusDescription
EXT-AUTH-01AExtend Authentication/Acct Status API
EXT-AUTH-03AAccount Creation API
EXT-AUTH-05APassword Management API
EXT-AUTH-30AAuthority Management API

Login

FeatureStatusDescription
EXT-AUTH-04ARewrite login, register, and admin pages to use APIs
EXT-AUTH-38Aad_form complain feature
EXT-AUTH-19ARewrite password recovery to use API
EXT-AUTH-21ARewrite email verification with API
EXT-AUTH-28AUsername is email switch

Users will log in using a username, a authority, and a password. The authority is the source for user/password verification. OpenACS can be an authority itself.

Each user in OpenACS will belong to exactly one authority, which can either be the "local" OpenACS users table, in which case the Index: openacs-4/packages/acs-core-docs/www/form-builder.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/form-builder.html,v diff -u -r1.18 -r1.19 --- openacs-4/packages/acs-core-docs/www/form-builder.html 24 Jun 2004 10:44:39 -0000 1.18 +++ openacs-4/packages/acs-core-docs/www/form-builder.html 29 Jun 2004 15:50:15 -0000 1.19 @@ -1,4 +1,4 @@ -Using HTML Forms

Using HTML Forms

Overview

Multi-part Elements

Some elements have more than one choice, or can submit more than one value.

SELECT elements

  1. Creating the form element.�Populate a list of lists with values for the option list.

    set foo_options [db_list_of_lists foo_option_list "
    +Using HTML Forms

    Using HTML Forms

    Overview

    Multi-part Elements

    Some elements have more than one choice, or can submit more than one value.

    SELECT elements

    1. Creating the form element.�Populate a list of lists with values for the option list.

      set foo_options [db_list_of_lists foo_option_list "
           select foo,
                  foo_id
             from foos
      @@ -43,5 +43,5 @@
           ns_set print $mypage
       }
           

    Common Errors

    Here are some common errors and what to do when you - encounter them:

    Error when selecting values

    This generally happens when there is an error in your + encounter them:

    Error when selecting values

    This generally happens when there is an error in your query.

    ($Id$)
    View comments on this page at openacs.org
    Index: openacs-4/packages/acs-core-docs/www/i18n-convert.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/i18n-convert.html,v diff -u -r1.14 -r1.15 --- openacs-4/packages/acs-core-docs/www/i18n-convert.html 24 Jun 2004 10:44:39 -0000 1.14 +++ openacs-4/packages/acs-core-docs/www/i18n-convert.html 29 Jun 2004 15:50:15 -0000 1.15 @@ -71,7 +71,7 @@ test. If you don't provide the package_key argument then all packages with catalog files will be checked. The script will run its checks primarily on en_US xml catalog files. -

Avoiding common i18n mistakes

  • Replace complicated keys with longer, simpler keys.�When writing in one language, it is possible to create clever code to make correct text. In English, for example, you can put an if command at the end of a word which adds "s" if a count is anything but 1. This pluralizes nouns correctly based on the data. However, it is confusing to read and, when internationalized, may result in message keys that are both confusing and impossible to set correctly in some languages. While internationalizing, watch out that the automate converter does not create such keys. Also, refactor compound text as you encounter it.

    The automated system can easily get confused by tags within message texts, so that it tries to create two or three message keys for one long string with a tag in the middle. In these cases, uncheck those keys during the conversion and then edit the files directly. For example, this code:

      <p class="form-help-text"><b>Invitations</b> are sent,
    +      

Avoiding common i18n mistakes