Index: openacs-4/packages/acs-core-docs/www/subsites-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/subsites-design.html,v diff -u -r1.39 -r1.39.2.1 --- openacs-4/packages/acs-core-docs/www/subsites-design.html 25 Apr 2018 08:38:28 -0000 1.39 +++ openacs-4/packages/acs-core-docs/www/subsites-design.html 2 Mar 2019 19:30:06 -0000 1.39.2.1 @@ -1,125 +1,50 @@ -Subsites Design Document

Subsites Design Document

- - -<authorblurb> -

By Rafael H. Schloming

-</authorblurb>
- -

*Note* This document has not gone through the any of the +Subsites Design Document

Subsites Design Document

By Rafael H. Schloming

+ OpenACS docs are written by the named authors, and may be edited + by OpenACS documentation staff. +

*Note* This document has not gone through the any of the required QA process yet. It is being tagged as stable due to high -demand.

- -

Essentials

- - - - - -
- -

Introduction

- - - - -

An OpenACS 4 subsite is a managed suite of applications that work together for +demand.

Introduction

An OpenACS 4 subsite is a managed suite of applications that work together for a particular user community. This definition covers a very broad range of requirements: from a Geocities style homepage where a user can install whatever available application he wants (e.g. a single user could have their own news and forums), to a highly structured project subsite with multiple interdependent applications. Thus, flexibility in application deployment is -the overarching philosophy of subsites.

- -

Meeting such broad requirements of flexibility demands architecture-level +the overarching philosophy of subsites.

Meeting such broad requirements of flexibility demands architecture-level support, i.e. very low level support from the core OpenACS 4 data model. For example, the subsites concept demands that any package can have multiple instances installed at different URLs - entailing support from the APM and the Request Processor. Since the design and implementation directly associated with subsites is actually minimal, a discussion of subsites design is, in fact, a discussion of how core OpenACS 4 components implicitly support -subsites as a whole.

- - -
- -

Historical Considerations

- - - - -

The subsites problem actually has several quite diverse origins. It was +subsites as a whole.

Historical Considerations

The subsites problem actually has several quite diverse origins. It was originally recognized as a toolkit feature in the form of "scoping". The basic concept behind scoping was to allow one scoped OpenACS installation to behave as multiple unscoped OpenACS installations so that one OpenACS install could serve multiple communities. Each piece of application data was tagged with a "scope" consisting of the (user_id, group_id, scope) triple. In practice the highly denormalized data models that this method uses produced large amounts of very redundant code and in general made -it an extremely cumbersome process to "scopify" a module.

- -

Before the advent of scoping there were several cases of client projects +it an extremely cumbersome process to "scopify" a module.

Before the advent of scoping there were several cases of client projects implementing their own version of scoping in special cases. One example being the wineaccess multi-retailer ecommerce. (Remember the other examples and get -details. Archnet?, iluvcamp?)

- -

The requirements of all these different projects vary greatly, but the one +details. Archnet?, iluvcamp?)

The requirements of all these different projects vary greatly, but the one consistent theme among all of them is the concept that various areas of the web site have their own private version of a module. Because this theme is so dominant, this is the primary problem that the OpenACS4 implementation of -subsites addresses.

- - -
- -

Competitive Analysis

- - - - -

...

- - -
- -

Design Tradeoffs

- - - - -

The current implementation of package instances and subsites allows +subsites addresses.

Competitive Analysis

...

Design Tradeoffs

The current implementation of package instances and subsites allows extremely flexible URL configurations. This has the benefit of allowing multiple instances of the same package to be installed in one subsite, but can potentially complicate the process of integrating packages with each other since it is likely people will want packages that live at non standard URLs to operate together. This requirement would cause some packages to have more configuration options than normal since hard-coding the URLs would not -be feasible anymore.

- - -
- -

API

- - - - -

This section will cover all the APIs relevant to subsites, and so will -consist of portions of the APIs of several systems.

- -

Packages

- -

The following package is provided for instantiation of packages. The +be feasible anymore.

API

This section will cover all the APIs relevant to subsites, and so will +consist of portions of the APIs of several systems.

Packages

The following package is provided for instantiation of packages. The apm_package.new function can be used to create a package of any type known to the system. The apm_package_types table can be queried for a list of -installed packages. (See APM docs for more detail XXX: insert link here)

+installed packages. (See APM docs for more detail XXX: insert link here)

 
- 
-
-
-
 create or replace package apm_package
 as
 
@@ -175,25 +100,16 @@
 show errors
 
 
-
- - -

Site Nodes

- -

This data model keeps track of what packages are being served from what +

Site Nodes

This data model keeps track of what packages are being served from what URLs. You can think of this as a kind of rp_register_directory_map on drugs. This table represents a fully hierarchical site map. The directory_p column indicates whether or not the node is a leaf node. The pattern_p column indicates whether an exact match between the request URL and the URL of the node is required. If pattern_p is true then a match between a request URL and a site node occurs if any valid prefix of the request URL matches the site node URL. The object_id column contains the object mounted on the URL -represented by the node. In most cases this will be a package instance.

+represented by the node. In most cases this will be a package instance.

 
- 
-
-
-
 create table site_nodes (
     node_id     constraint site_nodes_node_id_fk
             references acs_objects (object_id)
@@ -210,7 +126,7 @@
     directory_p char(1) not null
             constraint site_nodes_directory_p_ck
             check (directory_p in ('t', 'f')),
-        -- Should urls that are logical children of this node be
+        -- Should URLs that are logical children of this node be
     -- mapped to this node?
         pattern_p   char(1) default 'f' not null
             constraint site_nodes_pattern_p_ck
@@ -220,15 +136,8 @@
 );
 
 
-
+

The following package is provided for creating nodes.

 
-
-

The following package is provided for creating nodes.

- - - -
-
 create or replace package site_node
 as
 
@@ -250,7 +159,7 @@
     node_id     in site_nodes.node_id%TYPE
   );
 
-  -- Return the node_id of a url. If the url begins with '/' then the
+  -- Return the node_id of a URL. If the url begins with '/' then the
   -- parent_id must be null. This will raise the no_data_found
   -- exception if there is no matching node in the site_nodes table.
   -- This will match directories even if no trailing slash is included
@@ -272,76 +181,26 @@
 show errors
 
 
-
- - -

Request Processor

- -

Once the above APIs are used to create packages and mount them on a +

Request Processor

Once the above APIs are used to create packages and mount them on a specific site node, the following request processor APIs can be used to allow -the package to serve content appropriate to the package instance.

+the package to serve content appropriate to the package instance.

 
- 
-
-
-
 [ad_conn node_id]
 [ad_conn package_id]
 [ad_conn package_url]
 [ad_conn subsite_id]
 [ad_conn subsite_url]
 
 
-
- - - -
- -

Data Model Discussion

- - - - -

The subsites implementation doesn't really have it's own data +

Data Model Discussion

The subsites implementation doesn't really have it's own data model, although it depends heavily on the site-nodes data model, and the APM -data model.

- - -
- -

User Interface

- - - - -

The primary elements of the subsite user interface consist of the subsite +data model.

User Interface

The primary elements of the subsite user interface consist of the subsite admin pages. These pages are divided up into two areas: Group administration, and the site map. The group administration pages allow a subsite administrator to create and modify groups. The site map pages allow a subsite administrator to install, remove, configure, and control access to packages. The site map interface is the primary point of entry for most of the things a -subsite administrator would want to do.

- - -
- -

Configuration/Parameters

- - - - -

...

- - -
- -

Future Improvements/Areas of Likely Change

- - - - -

The current subsites implementation addresses the most basic functionality +subsite administrator would want to do.

Configuration/Parameters

...

Future Improvements/Areas of Likely Change

The current subsites implementation addresses the most basic functionality required for subsites. It is likely that as developers begin to use the subsites system for more sophisticated projects, it will become necessary to develop tools to help build tightly integrated packages. The general area @@ -352,19 +211,4 @@ a particular configuration of site nodes/packages. As we build more fundamental applications that can be applied in more general areas, this feature will become more and more in demand since more problems will be -solvable by configuration instead of coding.

- - -
- -

Authors

- - - - -

rhs@mit.edu

- - -
- -
+solvable by configuration instead of coding.

Authors

rhs@mit.edu