Dynamic Object Type

Package Specification Summary for Package: dynamic-types

Summary:	Dynamic Object Type management API
Description:	Allows creation, manipulation and ui generation of dynamically generated object types.
Maturity:	New Submission or Maturity Unknown
This package depends on:	acs-kernel acs-content-repository acs-translations
Packages that depend on dynamic-types:	project-manager
Package parameters:	None

Bug Tracker Summary for Package: dynamic-types

There is no package with the name "dynamic-types" known to bug-tracker.

Code Metrics Summary for Package: dynamic-types

# Tcl Procs	0
# Tcl Lines	0
# Tcl Blank Lines	1
# Tcl Comment Lines	0
# Automated Tests	0
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	0
# ADP lines	0
# Include pages (dynamic-types/lib/)	0
# Documentation pages	0
# Documentation lines	0
Browse Source	Not installed
Github Repository:	https://github.com/openacs/dynamic-types/tree/oacs-5-10

 

cvs head version of project-manager requires dynamic-types

What does dynamic-types do?
Dynamic types allows you to create new OpenACS Object Types and add attributes to them through a Tcl API.

When should I use dynamic-types?
Dynamic types supports several use cases:

• Container Applications - meta-applications which define the necessary data model and code to perform a useful function but the extended data is decided by the administrator.
• Extending existing packages with dynamic data. As an example project manager has dynamic types support which allow third packages to add attributes to projects and tasks which can be edited using the standard interface for project manager.

Creating a Dynamic Type (Declaration)
There are three main ways to create dynamic types:

• As a user, through an application user interface.
• As a system administrator, through install.xml actions.
• As a programmer, through the Tcl API.

notes:

a 2005 implementation example

Running Applications built on dynamic-types

The project manager package (latest version in HEAD) relies on dynamic types to allow custom applications and other packages (like invoices, logger) to extend the basic attributes of a project and a task. This is in use by three clients of cognovís.

Solution Grove has been exploring helping clients build dynamic data models with dynamic types.

Two examples we have are about bulk data collection, aggregation, and analysis. In both cases, data is uploaded to the system, where a web user interface is providing for viewing and aggregating the data.

In the first case, there is an administrative user interface to define a new type, and arbitrarily many types can be created. Each new type of data collection gets a different table/dynamic type in the database. Here we are mainly using the dynamic type system to programatically build new tables for collection. We also use the dynamic type definitions to build the user interface to explore the data after it has been uploaded. Storing all the data in a specific table, instead of generic storage, makes the reporting and dynamic analysis of the data much easier to code for. Doing sum, average, etc calculations on the data is greatly simplified. In this case we are collection many different types of data, and doing unique analysis on each type, so the ability to create the types, and build a user interface to it, on the fly is very helpful. The data collection is done through transfer of XML files with an external application. Using the dynamic-type attribute info we are able to map the XML structure to the various dynamic data collection types.

For another client, we are using dynamic types to give the site administrators more flexibility in developing their application. The client wants to allow users to upload specialized data files, but then to organize these files in ways that make sense to the client and their users. So, we developed 4 dynamic-type objects (institution, ward, glucose_file and glucose). An institution can have multiple wards, which can have multiple glucose_files which can have multiple glucoses. The attributes of each object is set by the site-administrator, and the plan is to adjust them over time as the site's needs change. Because everything is done with the Web UI, the administrator can make changes as they need to. The add-edit pages respond automatically to any changes in the attributes - there's no need to recode them when you add an attribute to an object.

A third application we have developed is a generic resource database, where a form can be generated to collect information such as a list of businesses, or other resources. The dynamic UI here can be integrated with categories to build a dynamic form for data entry. We also built a dynamic UI to view lists and individual entries.

 

Xarg Examples 

Xarg have developed two 'products' which are installed for multiple clients. In each case we used dynamic types to handle sections of data which are expected to be different for each client installation. Dynamic types allowed the system to handle the different data sets without needing to modify the code for each client.

dotCommunity: In our dotCommunity product users are able to create community websites by filling in an application form.  The system supports multiple community 'types'.  Dynamic types allows each clients to collect and display different data for each community type on a per installation basis.

dotConsult: This is our e-consultation product which uses dynamic types to store a flexible set of demographics information for the users taking part in the consultation.

Future Directions

The current APIs of dynamic-types are under revision, a much more consistent, and less abstract API is under development. It does not appear an upgrade from the older API will be easy to write.  In the long run support for "lists" as AMS has them would be a nice feature in addition to the option to store the additional types and attributes in a meta database (as AMS does) or in the primary tables (as dynamic types does currently). Dynfield (an application from Project Open) supposedly does exactly that, but for reasons unknown to me (MS) it has never made it into proper OpenACS and therefore any of it's packages.

 

Difference to AMS

 

The AMS package allows you to extend any object_type with additional attributes. These attributes are stored in a meta table, allowing you to quickly change the makeup of you objects without the need to change anything in the database. Additionally, through the support of "lists" for object_types, you can compose the entry forms for objects in multiple different ways, thereby allowing many different views on the same object_type.