The following is a requirements document for ACS 4 Subsites, part of the ACS 4 Kernel. The Subsites system allows one ACS server instance to serve multiple user communities, by enabling the suite of available ACS applications to be customized for defined user communities.
Many online communities are also collections of discrete subcommunities, reflecting real-world relationships. For example, a corporate intranet/extranet website serves both units within the company (e.g., offices, departments, teams, projects) and external parties (e.g., customers, partners, vendors). Subsites enable a single ACS instance to provide each subcommunity with its own "virtual website," by assembling ACS packages that together deliver a feature set tailored to the needs of the subcommunity.
The ACS subsite system allows a single ACS installation to serve multiple communities. At an implementation level this is primarily accomplished by having an application "scope" its content to a particular package instance. The request processor then figures out which package_id a particular URL references and then provides this information through the ad_conn api (
[ad_conn package_id],[ad_conn package_url]).
The other piece of the subsite system is a subsite package that provides subsite admins a "control panel" for administering their subsite. This is the same package used to provide all the community core functionality available at the "main" site which is in fact simply another subsite.
The Subsites functionality is intended for use by two different classes of users:
- Package programmers (referred to as 'the programmer') must develop subcommunity-aware applications.
- Site administrators (referred to as 'the administrator') use subsites to provide tailored "virtual websites" to different subcommunities.
Joe Programmer is working on the bboard package and wants to make it subsite-aware. Using [ad_conn package_id], Joe adds code that only displays bboard messages associated with the current package instance. Joe is happy to realize that ad_parameter is already smart enough to return configuration parameters for the current package instance, and so he has to do no extra work to tailer configuration parameters to the current subsite.
Jane Admin maintains www.company.com. She learns of Joe's work and would like to set up individual bboards for the Boston and Austin offices of her company. The first thing she does is use the APM to install the new bboard package.
Next, Jane uses the Subsite UI to create subsites for the Boston and Austin offices. Then Jane uses the Subsite UI to create bboards for each office.
Now, the Boston office employees have their own bboard at http://www.company.com/offices/boston/bboard, and similarly for the Austin office. At this point, the Boston and Austin office admins can customize the configurations for each of their bboards, or they can just use the defaults.
A subsite API is required for programmers to ensure their packages are subsite-aware. The following functions should be sufficient for this:
10.10.0 Package creation
The system must provide an API call to create a package, and it must be possible for the context (to which the package belongs) to be specified.
10.20.0 Package deletion
The system must provide an API call to delete a package and all related objects in the subsite's context.
10.30.0 Object's package information
Given an object ID, the system must provide an API call to determine the package (ID) to which the object belongs.
10.40.0 URL from package
Given a package (ID), the system must provide an API call to return the canonical URL for that package.
10.50.0 Main subsite's package_id
The system must provide an API call to return a package ID corresponding to the main subsite's package ID (the degenerate subsite).
The Programmer's User Interface
There is no programmer's UI, other than the API described above.
The Administrator's User Interface
The UI for administrators is a set of HTML pages that are used to drive the underlying API for package instance management (i.e. adding, removing, or altering packages). It is restricted to administrators of the current subsite such that administrators can only manage their own subsites. Of course, Site-Wide Administrators can manage all subsites.
20.10.0 Package creation
20.10.1 The administrator should be able to create a package and make it available at a URL underneath the subsite.
20.20.0 Package deactivation
20.20.1 The administrator should be able to deactivate any package, causing it to be inaccessible to users.
20.20.5 Deactivating a package makes the package no longer accessible, but it does not remove data created within the context of that package.
Document Revision # Action Taken, Notes When? By Whom? 0.1 Creation 08/18/2000 Dennis Gregorovic 0.2 Edited, reviewed 08/29/2000 Kai Wu
Last Modified: requirements.html,v 1.1 2001/01/21 01:39:49 bquinn Exp