Index: openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp,v diff -u -r1.2 -r1.3 --- openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp 24 Oct 2001 23:27:22 -0000 1.2 +++ openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp 29 Mar 2002 17:21:56 -0000 1.3 @@ -15,211 +15,174 @@ The dotLRN architecture attempts to define a framework within which learning communities develop. A learning community may take many -different forms, but remains the crux of the architecture. +different forms but remains the crux of the architecture. -

Learning Community

+

dotLRN Community

-A Learning Community is architected as a series of +A dotLRN Community is architected as a series of OpenACS components, with a heavy use of the subsite concept. One community is represented by: -

Class Instances & Clubs

+

OpenACS Group

+The core dotLRN group type is dotlrn_community. This group +type defines some basic attributes that all communities have: + + There are two different types of learning communities in the basic dotLRN release: class instances and -communities (clubs). Both have the same functional -capabilities but have different attributes and roles for their -respective members. +clubs. While Clubs need no additional attributes, +Class Instances require information concerning the Term and Year of +the Class Instance. -

Class Instances

-Class Instances are related to a particular class, and must specify: - +

Site Node

-The fist three parameters may be stored as separate items, all in one, -or combined in some way. The current architectural direction is to -separate Year and to group Term and Section, but this may change. In -terms of the global architecture, this isn't very important. +In dotLRN, a community is mounted only at one particular node. In the +future, if communities end up being multi-mounted, there will have to +remain a canonical location for the community in order to ensure +maximal modularity - specifically the ability to point to a +community's URL using only the community_id as a starting +point. -

+

Instance of dotLRN Community Manager

-Since all class instances have a common basic set of parameters, the -class instance groups should all be a single core group type, called -dotlrn_class. The dotlrn_class group type defines the -attributes above (year, term, section). dotlrn_class is a -group type that subtypes dotlrn_community. +The core dotLRN OpenACS package is called dotlrn +(surprisingly enough). This package is meant to be remounted to handle +community types and specific communities. A package_id +corresponds to each community.

-In addition, in order to group class instances by the class they refer -to, the dotlrn_class group type is subtyped into further group -types, where one class is itself a group type. For example, -6.001 is a group type, whose parent group type is -dotlrn_class. Then, 6.001 is the group type that all -instances of 6.001 belong to. 6.001 - Spring 2002, Section B -is a group of group type 6.001. This architecture allows for: +The group types for these two dotLRN Community Types are +dotlrn_class_instance and dotlrn_club. -

+

Use of NPA

-

Communities (Clubs)

+dotLRN makes heavy use of the New Portal Architecture. -Clubs are fairly generic Learning Communities, with no specific -attributes. Clubs are timeless, in that they don't start and end on -certain dates. Membership lists evolve, but the clubs remain unique, -without instances. +

+Each full-access user has a personal portal where all data from all +communities is centralized in one place. This is called the dotLRN +User Portal. +

-Thus, unlike class instances, the group type structure for clubs can -be much simplified. A root group type, called dotlrn_club can -encompass all club groups without any additional level of group typing. +Each community has a non-member portal which displays information +to those browsing the system and wanting to find out more about a +community before joining it. This is called the dotLRN Community +Non-Member Portal. +

-

dotLRN Packages

+Each community also has an administrative portal which centralizes all +administrative functionality for that community. This is called the +dotLRN Community Admin Portal. -Learning communities have various packages of functionality. These -packages are much like existing OpenACS 4 packages, but with added -specifications, special callback interfaces, and predictable APIs that -not every OpenACS 4 package will have. +

+Finally, each community member has her own dotlrn Community Member +Portal. The important distinction here is that there is a +different portal for each member of this community. Thus, if a +community has 100 members, there are 100 individually managed +portals. These portals are initially created from the dotLRN +Community Portal Template that administrators of the community control. + +

dotLRN Applets

+ +dotLRN Communities have various packages of functionality. These +packages (dotLRN applets) are much like existing OpenACS 4 +packages, but with added specifications, special callback interfaces, +and predictable APIs that not every OpenACS 4 package will have. +

-Thus, a dotLRN Package is composed of three OpenACS 4 -packages: +Thus, a dotLRN Applet is composed of three +pieces that may each be a separate OpenACS package:

-The relationship between the NPA and the portlet package are defined -using ACS Service Contract. This is described in greater detail -in The Portal Interface (futher down). +

NPA Interactions

+The relationship between the NPA and the portlet functionality is +explored in the NPA Architecture Manual. +

+

dotLRN Applet API

+ The relationship between dotLRN and the specific dotLRN-dependent -packages (dotlrn-bboard, dotlrn-faq, etc...) is also defined using +packages (dotlrn-bboard, dotlrn-faq, etc...) is defined using ACS Service Contract. ACS Service Contract defines a standard provider/consumer interface with special contract APIs. The dotLRN system defines the dotLRN Applet Contract, which includes the following operations:

The specifics of creating a dotLRN package are described in the dotLRN Package Creation Guide. -

The Portal Interface

-dotLRN will present most of its interface in portal form. Each dotLRN -package will present its information inside a portlet within -the appropriate portal page. - -

- -The current Portals package is inappropriate for this effort, given -that there is no clean API for creating portal pages, setting up -portal pages configuration, and rendering portal pages -programmatically. Instead, dotLRN will need a much more programmatic -portal mechanism. - -

A Portal Page

- -The New Portals Architecture (NPA) will feature the -ability to programmatically create and edit single Portal -Pages. A single Portal Page will be defined by: - - -

- -The dotLRN application will then create, configure, and associate -individual portal pages with specific users' sections of the -site. This will allow portal functionality to exist within the dotLRN -application without handing over all control to the portals package. - -

Portlets

- -The NPA will require portlet packages much like the old portals -package. Each portlet package is responsible for: - - -

The Per-User Interface

- -Each user will have a single NPA interface which groups information -from all dotLRN classes in one page. Given the subsited architecture -of each class, the per-user interface must be subsite aware, and must -be able to query information across subsites. - -

- -The per-user interface will use slightly different portlets than the -community-specific ones, given that those portlets will require -scanning information across package instances. There is some thought -that this may be "not so kosher." As long as the cross-package -information is kept to a minimum, though, it should be just -fine. We'll make sure to keep associating packages with the -communities they belong to. -

- <%= [dotlrn_footer] %>