Development the OO-Framework for OpenACS:

Improving Scalability and Applicability

Gustaf Neumann • Vienna University of Economics and Business Administration

Summary

Object oriented access/development for all types of acs-objects
Ability to subclass packages (make packages first class citizens, reusability of package parameters)
Scalability of property management (package parameters, portal parameters)
Subclassing of Widgets
More flexible cluster management
Initial Microformat support
Improved composability and personalization through a more powerful portal system

Improvements to the Framework

Object oriented access/development for all types of acs-objects
Ability to subclass packages (make packages first class citizens, reusability of package parameters)
Scalability of property management (package parameters, portal parameters)
Subclassing of Widgets
More flexible cluster management

OO Interface for DB

OO Interface for existing and application specific acs-object-types

Loading schema information from acs-object-types and acs-attributes and create automatically XOTcl classes from this information

Creating new XOTcl Classes as persistent classes using the OpenACS conventions by subtyping existent classes

# Fetch base classes from OpenACS Schema
::xo::db::Class get_class_from_db -object_type party
::xo::db::Class get_class_from_db -object_type person

# Create new Object type with two additional attributes
::xo::db::Class create ::demo::employee \
    -superclass ::xo::db::person \
    -slots {
      ::xo::db::Attribute create salary -datatype integer
      ::xo::db::Attribute create dept_nr -datatype integer -default "0"
    }

Generated SQL Table

dotlrn-test5=# \d demo_employee

   Table "public.demo_employee"
   Column    |  Type   | Modifiers 
-------------+---------+-----------
 dept_nr     | integer | default 0
 salary      | integer | 
 employee_id | integer | not null

Indexes:
    "demo_employee_employee_id_pk" 
        PRIMARY KEY, btree (employee_id)

Foreign-key constraints:
    "demo_employee_employee_id_fkey" 
        FOREIGN KEY (employee_id) 
        REFERENCES persons(person_id) 
        ON DELETE CASCADE

Subclassing Packages

Use Case s5-package

Inherits most from XoWiki, some own functionality
No need to duplicate e.g. package parameter etc.

::xo::db::require package xowiki

::xo::PackageMgr create ::s5::Package \
    -package_key "s5" -pretty_name "S5" \
    -superclass ::xowiki::Package

Property Management (Package Parameters, Portal Parameters)

Property management of OpenACS/DotLRN is wasteful and not sufficiently scaling:

For every package instance, one package value is copied for every package parameter
Adding parameters is costly (#packages × #parameters)
Changing parameter defaults has no effect for existing packages

Package Parameter Redundancy

Real world data:

Learn@WU: Currently 0.3 mio entries,
Galileo: > 2mio entries
Small OpenACS installations: 1000 objects (38 package instances)

High degree of redundancy (many values are stored 4000 with the default value)

Learn@WU: from 300000 entries → only 406 necessary entries needed (non-default)

OO Package Parameter Interface

Implementation of base functionality

parameter get_from_package_key: 5× faster
parameter get: 2× faster

Supports inheritance from different packages, uses oacs-datamodel, cluster-safe

Missing:

user interface
alternate permissions for changing/deleting per-package-instance

Additional Developments

Generalized Cluster Management

Basic OpenACS functionality: flush util-memoize caches
New implementation: ability to perform configurable operations clusterwide
Necessary for e.g. Univ.Valencia to make use of Ajax-based Chat in cluster configurations

Subclassable Widgets

Ability to define "HTML objects" supporting subclassing with

input interface (for forms) and
ouput interface

Form-Fields (see tutorial)

Improvements in XoWiki

Initial Microformat support for XoWiki
Improved composability and personalization through a more powerful portal system

Microformat support in XoWiki

Microformats:

make Semantic Web reality

Current support in XoWiki:

hCalendar: announcements of talks and workshops,

export e.g. via Firefox extensions tails, operator, and
iCal subscription (subscribe to XoWiki instance, similar idea as RSS)

rel-tags: microformat for tags, see e.g. openacs.org

E-Learning News with embedded Microformats

Export embedded events via tails

Export embedded events via iCal

XoWiki Portal System

Analysis of the DotLRN Portal System

Rethink Concepts in a bigger picture

composability
personalization
flexibility

Joint work with Michael Aram

Structure of DotLRN Portal System

Types of Portals in DotLRN

2 Types

User Portal (home)
Personalization through all memberships
Community Portals

Classes
Communities
Subgroups

Community Portals provide Member and Non-member Portals

Structure of the DotLRN Portal System

Shortcomings:

Rigid 3 level structure (portal-pages are tabs, portal pages have to be in portals, portlets have to be in portal pages, etc.)
Weak framework integration limits flexibility (e.g. it is not possible to use a "Portlet" on the Start-page, summarizing e.g. contents of two communities)
Old-fashioned and limited portal page composition (quite complex to add new kinds of portlets, ...)

Design Principles of the XoWiki based Portal system

Provide different kind of renderers: plain, mobile, css, ajax

Separate structure classes ("model" in MVC) from renderers ("views", implemented via mixin classes)

Provide new composite page types

for tabs (similar as portal + portal_pages)
and composite pages (with flexible drag&drop interface in Ajax mode; similar as portal_page and portal element)

Provide revisions of a portal

Every XoWiki page can be part of a composite page type

Every includelet, every XoWiki page can be used as a portlet.

TabView and Composite Page in XoWiki

XoWiki Page as Portal Page

Composite Page with 3 Column Layout and Meshup Elements

Composite Page with different renderer

Integration with DotLRN

Approach: turn DotLRN portlets into includelets

One includelet per different kind of DotLRN portlet defined
Every includelet has parameter community_id

"all" ⇒ use communities, the user is a member
single or multiple community_ids
Community_id can be as well provided form the composite page or context

Consequence: Possible to have e.g. a subset of memberships on some portal pages, or to place e.g. the announcements of some communities to a start-page

Community Portal

Community Portal in Edit-Mode

Personal Portal

Community Portal after Drag & Drop

Personalization

Approach:

Tabs and composite pages are implemented via Form-Fields
Form-Fields can be personalized via Roles
Currently defined roles: swa, register_users, unregistered_users admin, creator, app_group_member, community_member
Foreach role:

Possible to show/hide includelets
Possible to provide completely different sets of includelets

Consequence: Possible to have e.g. different portal pages for some communities where user are not logged in, or where they have certain roles, ...

Development the OO-Framework for OpenACS:

Gustaf Neumann • 03-26-2008

Development the OO-Framework for OpenACS:

Summary

Improvements to the Framework

OO Interface for DB

Generated SQL Table

Subclassing Packages

Property Management (Package Parameters, Portal Parameters)

Package Parameter Redundancy

OO Package Parameter Interface

Additional Developments

Improvements in XoWiki

Microformat support in XoWiki

E-Learning News with embedded Microformats

Export embedded events via tails

Export embedded events via iCal

XoWiki Portal System

Structure of DotLRN Portal System

Types of Portals in DotLRN

Structure of the DotLRN Portal System

Design Principles of the XoWiki based Portal system

TabView and Composite Page in XoWiki

XoWiki Page as Portal Page

Composite Page with 3 Column Layout and Meshup Elements

Composite Page with different renderer

Integration with DotLRN

Community Portal

Community Portal in Edit-Mode

Personal Portal

Community Portal after Drag & Drop

Personalization