Index: openacs-4/packages/acs-reference/www/doc/design.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-reference/www/doc/design.adp,v diff -u -N --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/acs-reference/www/doc/design.adp 27 Oct 2014 16:39:43 -0000 1.2 @@ -0,0 +1,59 @@ + +{/doc/acs-reference {ACS Reference Data}} {acs-reference Design Documentation} +acs-reference Design Documentation + + + +

acs-reference Design Documentation

I. Introduction

Reference data services are often overlooked in the rush to get +coding. Much of the code is redundant or of similarly patterned +implementations. This package intends to address some common +features and needs.

II. Historical Considerations

Before the existence of acs-reference, the ACS required that you +preload some tables in a script to get some basic reference +functionality. There were many problems with this:

No easy way to find out what reference data even existed.
No way to find out how old the data was.
No way to find out where that data came from.
Very US/English slant on the data.

III. Design Tradeoffs

Primary Goals

This system was designed with maintainability and reusability +as its primary goals. By wrapping a layer around all of the +reference tables we have increased the maintainability +immensely.
Another goal was to bring together many different types of data +and present them in a logical fashion. It was amazing how little of +this data is available on the internet in a database friendly +form.

Performance

+When updating the reference tables their is overhead due to the +fact that the table is registered with the repository. This should +rarely occur anyway as the tables are only added once. By not +having the actual data itself in the acs-object system, subsequent +additions and deletions to the reference tables themselves are +unaffected by this overhead. +

IV. API

See api-browser +

V. Data Model Discussion

The UNSPSC reference data has a data model for handling data +revisions. An application can determine any new/revised category +based on existing, obsolete data.

VI. User Interface

Their is no end user interface. There needs to be some kind of +admin UI to report status and possibly manage updates per +requirements.

VII. Configuration/Parameters

None

VIII. Future Improvements/Areas of Likely Change

A server based update mechanism will be supported. This will +allow for tables to be updated (and preferably diffed) instead of +being reloaded with a package upgrade. An interface to produce +xml/csv from the reference data would be a nice service to the +community (allowing legacy applications a way to import this +data).

IX. Authors

Jon Griffin

X. Pre-CVS Revision History

+$Log: design.adp,v $
+Revision 1.1.2.1  2014/09/17 18:35:54  gustafn
+- prettify documentation (use master templates)
+
+Revision 1.4  2006/08/06 20:40:20  torbenb
+upgrading html, closing li p tags, adding quotes to tag attributes
+
+Revision 1.3  2006/08/06 18:54:02  torbenb
+added documentation commentary, applied bs filter, renumbered sections
+
+Revision 1.2  2006/08/06 18:30:57  torbenb
+removing c-Ms, wrapping text with p tags, added link to api-browser in api section
+
+Revision 1.1  2001/04/22 00:53:12  jong
+initial openacs import
+
+Revision 1.2  2000/12/13 04:39:00  jong
+Added Revision History and corrected typo in reference link
+