|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.
OpenACS developer documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.
list documentation assumptions, such as familiarity with modifying OpenACS packages. All kernel docs are here etc.
This documentation should be written for ongoing use by developers, not as a tutorial.
List of practical development and diagnostics tools and methodologies.
List of OpenACS development resources, api-doc, schema-browser, developer-support package etc.
Identify each OpenACS subsystem, explain why it is used (instead of other choices). In the case of subsystems that are developed outside of OpenACS such as tcl, include external references to development and reference areas.
Show current engineering standards and indicate where changes to the standards are in the works.
Sections should be dedicated to DotLRN standards as well, if they are not available elsewhere.
Add overview diagrams showing the core parts of the datamodel including an updated summary of Greenspun's Chapter 4: Data Models and the Object System
package design guidelines and development process templates including planning, core functions, testing, usability, and creating case studies
Standard package conventions, where to see "model" code, and guidelines (or where to find them) for:
programming tcl/sql
using the acs-api
ad_form
coding permissions
OpenACS objects
scheduled protocols
call backs
directory structure
user interface
widgets
package_name and type_extension_table
adding optional services, including search, general comments, attachments, notifications, workflow, CR and the new CR Tcl API
Document kernel coding requirements, strategy and guidelines to help code changers make decisions that meet kernel designers' criteria
Comments