(Sketch for) OpenACS Home

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:20 AM

OpenACS (Open Architecture Community System) is a toolkit for building scalable, community-oriented web applications. OpenACS is the foundation for many products and websites, including the .LRN e-learning platform. OpenACS is open source and is available under the GNU General Public License.

Why use OpenACS?

OpenACS is unique in the breadth of services it offers developers and administrators. Millions of dollars and decades of developer time have gone into the maturation of OpenACS.

You can read the technical reasons to use OpenACS.

How do I install OpenACS?

The installation documentation contains all the necessary steps to install OpenACS on a large variety of systems. There is also a Windows Installer and other packaged installations openacs-system-install. Also Check the installation requirements before installing. The current stable release is OpenACS 5.9.0 (cvs aliases).

How do I work with OpenACS?

You can start by reading the documentation, specifically tips on customizing, the developer's tutorial, and
the FAQs. There is a OpenACS Wiki and a list of packages that extend OpenACS.

For professional help, contact one of the OpenACS companies.

OpenACS Community

One of the strengths of the OpenACS project is the community surrounding it:

• Discussion forums
• Blog
• IRC at irc://irc.freenode.net/#openacs
• Chatroom logs and today's log
• File Storage
• How to contribute
• Test servers
• CVS Browsers options: Browser, https://github.com/openacs
• Technical Decisions on the direction of OpenACS, made by the community-elected OpenACS Core Team.

News

Recent Posts

{legacy} Proposed project goals

Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 04:18 AM

This page remains for legacy discussion.

This is regarding Approach 1. in en:Documentation_Project_Discussion. The milestones are performance based, instead of directly connected to work, which makes them an impractical plan to follow.

Overview: 

Here are a few things we are working to accomplish with XoWiki and the OpenACS website:

Milestones:

MILESTONE I:  Tooling Up - Before We Can Accomplish Anything We Must Have a Powerfull Wiki.

- XoWiki is functional for the most part

- a few bugs and feature requests remain, Gustaf and Dave have rocked the OACS boat and created some amazing functionality in a short period of time.  When some of these items are cleared this Milestone will be considered accomplished.
 

MILESTONE II:  Testing Packages after each OACS release.

- XoWiki is functional, we can start testing immediately.  Look for a TESTING PROCESS document in the PACKAGES category (if it's not up now, soon).

 
MILESTONE III: Look and Feel vs. Content

- XoWiki is turning out to be very powerfull and easy to use.  We will need to focus on content first, look and feel can be handled later.  UTILITY has a greater priority over LICKABILITY.

MILESTONE IV: Fanatical Documenation.

- API documenation will stay as is.

- see en:Documentation_Project

MILESTONE V: New Blood.

- I think we can start attracting new devs as soon as our Documentation allows a new developer easy egress into the toolkit.  Watching Dave, Gustaf and others litterally create new functionality out of thin air over the last week of January 2K6 is clear indication the barrier to entry is not the toolkit, it is with the resources and tools they need to be able to understand and become developers. 

- I think getting a LICKABLE look and feel is something that can be done simultaneously, at a stage after XoWiki has been thoroughly debugged and tested.

2006 Session 1: Towards full Accessibility in LMS

Created by Olga C. Santos, last modified by Benjamin Brink 29 Jun 2017, at 04:11 AM

Overview:

Accessibility status in .LRN

Objectives:

1. Analyze the accessibility status of .LRN/OpenACS and discuss the existing main problems and the way to solve them.
2. On-going developments and research works on accessibility compliance in LMS
3. Educate .LRN community in the importance of developing with accessibility requirements in mind
4. Define some guidelines to help .LRN developments reach the accessibility requirements
 

Scheduling:

Keynote: Accessibility in Community and Open Source Software Developments: the Moodle perspective

Martyn Cooper - Head of Accessible Educational Media team at the Open University in the UK

Among diverse research and internal consultancy roles Martyn Cooper has overall responsibility for accessibility in the Open University's VLE which is based on Moodle.  The Open University has nearly 10,000 disabled students and takes its legal and moral responsibility to give them equal access to its teaching and learning very seriously.  It has been making substantial investment within the Moodle community to address the current deficits in accessibility of the software.  This paper reflects on this process and more general issues of accessibility in community based and open source software developments.

6/8 Papers (20 min each + 5 minutes questions)

• Innovation and Research accessibility issues on eLearning: a user modelling approach [Jesús G. Boticario]
• Accessibility requirements in .LRN [Olga C. Santos]
• More talks to be selected

Discussion among the participants regarding the topics presented previously and others that arise

Conclusions from the session to feed back .LRN/OpenACS community

Proposals:

You can send the proposals for papers to the Workshop call or to the contact below.

Contact:

For questions contact Olga C. Santos
R&D Technical Manager
aDeNu Research Group (UNED)     

 
Last modified: 2017-06-29 04:11:17.78443+02

2007 Project Ideas for Google Summer of Code

Created by Matthew Burke, last modified by Benjamin Brink 29 Jun 2017, at 04:09 AM

Listing of potential projects for the Google Summer of Code 2007.

.LRN is serving as the mentoring organization for this project, but because .LRN is almost exclusively built on top of the OpenACS Web Application Toolkit  project ideas that benefit one or both are welcome.

• Projects that improve or add to the web accessibility of both .LRN and OpenACS for the disabled (please contact the .LRN leadership team with questions and requests for details about the related .LRN Zen Project: honchos [at] dotlrn [dot] org)
• Projects that improve or add to the translation infrastructure (e.g. translation server and translation package) to  better support non-English speaking users (OpenACS/.LRN has an advanced translation infrastructure that has a web UI for translation, but it could use some help). Examples:
  • Projects focused on improving version management and term alignment across languages
  • Projects focused on adding translation support tools
  • Projects focused on helping teams collaborate on specific localizations online (improved version control etc.)
• Projects that add or improve E-Learning standards compliance in .LRN (e.g. IMS LD, IMS QTI 2.0/2.1, SCORM 2004 3rd Revision)
• Projects that focus on application integration (e.g. adding comments package support across all applications, adding ratings package support across all applications)
• Projects that focus on object orientation support and agile software development
• Projects that extend the OpenACS workflow package (help make them more standards compliant, support state dependent attributes, etc.)
• Projects focused on game-based learning in online learning environments
• Projects focused on adding adaptive learning support to online learning environments
• Projects focused on improving the packaging and distribution of the software (e.g. apt-get/yum/etc.)

Suggestions:

1. When dealing with multiple translations a change in the source language creates a logistical problem b/c all target languages should be reviewed. The suggested work would focus on creating a notification system that informs translation teams when a term has been changed, offers a way to include a little note for the teams, and offers translators a quick way to reconcile the changes.
2. The large number of applications in .LRN/OpenACS results in multiple occurrences of the same term in different the various translation catalogs (e.g. the word "delete" is an example that is used often, appears in multiple applications, and should only have to be translated once). The suggested work would focus on a community glossary that integrates with the translation UI. For each object being translated glossary terms are highlighted in the base language and any relevant translations of the glossary items are presented along side the object being created/edited. The work should help build consistent use of terms in the source language's content and in any translations. A glossary can include phrases and abbreviations and warn translators when the terms are used in multiple packages.
3. Add functionality that analyzes translated message keys for words not in various spelling dictionaries as they might be candidates for correction.
4. On websites of sufficient size, a consistent look and feel for users is important, while for site publishers and administrators, de-coupling the UI from programming allows for easier maintenance. The OpenACS templating system provides a mechanisms that allows programmers to make changes to widgets that are then available across all applications. This makes it possible for a student to contribute in a way that has lasting effect across all applications. An example that could be worked on in the context of the GSoC: addition of some accessible AJAX functionality to the forum-building or list-building procedures.
5. IDE improvements:
   1. Eclipse improvements (contact Malte Sussdorff for ideas)
   2. Emacs improvements
   3. TextMate bundle support
   4. $your_favorite_ide support
6. Improve the functionality of nsgd. Nsgd is a module for aolserver that allows for dynamic graphics generation via Tcl scripting of the gd library. Nsgd has recently undergone a major revision but there are still a few important functions to be added including the following: allowing graphics to be shared between threads, integration with the charting module, and finish the implementation of a sparkline library.  In addition to benefiting .LRN and OpenACS, this work would be quite useful for any and all projects using AOLserver.
7. Reference management module. Needed functionality includes import/export of BibTeX data, generation of works cited lists in APA, MLS and other formats, and improved multi-user annotations.
8. Provide an automatic classification system for the reference management module.  Assign bookmarks to categories automatically using, perhaps, libbow.
9. Integrate AOLserver with AOL's Instant Messaging Library.  Not sure about the licensing.  Now that AOL has _finally_ released a library and granted permission for making AIMbots, create integration code so that AOLserver can send information via AIM as well as HTTP.
10. Create a module for compiling, linting, and other basic checks of uploaded student code.  In particular, support Eclipse and BlueJ.  Allow students in a .LRN class to upload source code which is compiled and tested.  Reports sent to student and teacher.
11. Explore using the IMS Learning Design specification support in .LRN to model adaptive learning experiences.
12. Explore integration of game-based learning tools with .LRN (e.g. passing results from an adaptive game back to .LRN)

2006 November 2nd (General Web Applications Focus - OpenACS)

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:07 AM

Keynotes and Schedule

Here is a list of topics people have expressed an interest in discussing at the LRN/OpenACS Fall Conference 2006

• Future of OpenACS platform
  • XOTcl's role in OpenACS
  • More focused platform/products to give you a head start (dotLRN, dotCommunity)
  • What is the potential of a kernel rewrite?
  • Timeline for a lickable openacs.org
  • Building an easy and complete installer
  • Supporting theming (better CSS/HTML local customizations)
  • Supporting accessibility requirements
  • Package Inheritance, better re-usability of code without forking
• OpenACS Best Practices
  • Automated Testing: How and Why (Dave Bauer)
  • Package Design

For those interested in participating in the 'what is the potential of a kernel rewrite?' discussion, here is a set of questions to think about.  They are aimed at establishing the general point of view of those taking part in the discussion; ie. you don't need to answer them now or post a long article justifying your perspective.  Simply knowing your answers and being able to compare them directly to other people in the discussion will help us get something useful out of it.  You may also find it useful to consider these questions first from an optimistic perspective and separately with your own assessment of what is realistic (as people will have wildly different opinions of what is practical which may in turn hide the fact that people agree in principle).

First some questions to establish the context of your thinking:

What state is OpenACS in now?

• Almost there or needs a lot of work?
• In need of radical, non-backwards compatible improvements or more conservative, backwards comparable improvements?
• In need of cross package architectural improvements or localized incremental improvements?
• In need of documentation/idealogical changes or practical code changes?

Would you like to see all effort focused on incremental improvement? radical change? both in parallel (if so how should it be organized)?

What is OpenACS?

• A toolkit (ie. complete components which can be brought together with glue code to make a complete system)?
• A template (ie. a system with blanks that need to be filled in to complete it)?
• A complete system (ie. only required configuration to get a finished system)?
• A content management system (ie. mainly for publishing)?
• A community / social networking system (ie. focused on delivering functionality to groups of non-admin users and enhancing the relationships between them)?
• A collection of highly interactive apps (ie. a forum, survey tool, etc and some navigation to get between them)?

If your not sure what it is now, what do you think it should be?

Should OpenACS require local customization or be entirely configurable?

Second some high level questions to establish your priorities:

What are your aims for an improved OpenACS?

• Easier exchange of code between developers? (ie consistent context)
• More people using OpenACS in total?
• Improve QA in releases?

How should the OpenACS architecture be decided? 

• By TIPs (if so how will the work be funded)? 
• By anyone how has the resources to write the supporting code (if so how will long term consistency be achieved)?

Thirdly some low level questions to get the basics of your practical proposals:

What do you like about OpenACS now?

What are the biggest problems with OpenACS now?

What is your OpenACS wishlist?

What are your OpenACS implementation plans in practice? 

2006 Fall Conference Interest in Attending

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:07 AM

.LRN/OpenACS Fall Conference 2006 - Interest in Attending (unofficial list to let people know you are coming)

Type your name here if you are planning or interested in attending the .LRN/OpenACS Fall Conference 2006. Include interests in parentheses

• Tracy Adams, ACSPropel, USA
• Don Baccus, USA
• Dave Bauer, SolutionGrove (Future of .LRN, Future of OpenACS, Best Practices, Automated Testing), USA
• Carl Blesius, MGH LCS (E-Learning, KM, .LRN), USA
• Matthew Burke, St. Mary's College of Maryland
• Carlos Delgado Kloos, Universidad Carlos III de Madrid, Spain
• Neophytos Demetriou, Cyprus
• Lee Denison, Xarg Ltd (Future of OpenACS, Best Practices, Automated Testing), UK
• Paul Griffiths, OHO (formerly ybos), (Personal Networking, Future of OpenACS), USA (Cambridge) 
• Ana Holzbach, MGH LCS, USA
• Volin Karagiozov, American University in Bulgaria (E-Learning, .LRN, Best Practices), Bulgaria
• Avni Khatri - UCLA CTRL (Best Practices, Educational apps, LDAP, Future of OpenACS,  Meeting people), USA
• Katherine Lau, MGH LCS
• Caroline Meeks, SolutionGrove
• Gustaf Neumann, Austria
• Emmanuelle Raffenne, Innova group, UNED, Spain
• Rocael Hernández Rizzardini, Viaro (Future of .LRN, Future of OpenACS, Best Practices, Automated Testing), Guatemala
• Olga C. Santos, aDeNu Research Group, UNED (Future of .LRN, dotLRN functionality status, .LRN Accessibility and Usability, .LRN Educational Standards support, SOA, Best practices, Teaching developers in .LRN/OpenACS technology, Research works based on .LRN, State of the art of other LMS, ...), Spain
• Jesús G. Boticario, aDeNu Research Group, UNED, Spain
• Stefan Sobernig, Austria
• Michael Steigman, USA
• Malte Sussdorff, cognovís (Future of OpenACS, Teaching OpenACS to others, SOA approaches, Meeting people & drinking beer), Germany Sorry, have to work in Amman / Jordan.
• Michael Totschnig, Austria
• Luis de la Fuente Valentín, Universidad Carlos III de Madrid, Spain
• Ryan Gallimore, Viscous Media, Canada
• Ben Li , Manish Hasija, Userful Inc, Canada 
• Álvaro Rendón, Universidad del Cauca, (Future of .LRN, Best Practices), Colombia
• David Wisniewski, Brandeis University, USA
• John Zhang, Bancova LLC, New Jersey, USA
• Nima Mazloumi, University of Mannheim, (Future of .LRN, Integration of XoTCL in OACS Core, OR-Mapping, IDE Integration), Germany
• Andrew Piskorski, USA.

Translation server for OpenACS packages

Created by Victor Guerra, last modified by Benjamin Brink 29 Jun 2017, at 03:32 AM

Goal

The goal of the project is the focus of the efforts regarding the internationalization of the OpenACS and .LRN packages. All the translations contributed in this server will be included in the releases of all the translations contributed to the site.

How to contribute on the translation server?

Just register for an account in the translation server ( http://translate.openacs.org/ ), read Getting Started ( http://translate.openacs.org/getting-started ) and start contributing! ( Which is the process for approving accounts ? Who gets the notifications where there is an approval pending? webmaster@openacs.org ?

Who is in charge of the translation server?

Which packages are installed in the translation server?

When is the translation server upgraded?

When the synchronization between the CVS and the translation server happens?

Issues regarding the translation server?

You can post on the forums or email to the OCT or HONCHOS email list.

Theming Project

Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 03:25 AM

OACS Theming Project 

XoWiki is getting to the point where we are going to be ready to use that live as our homepage.

However before we consider making XoWiki our website CMS, we need to consider the idea of theming first.

Some ideas on how theming would work:

The basic idea is the use of translation keys.  so you have something like this #­theme.add_icon# and then your theme package has the translation of that to  <img src="/resources/mytheme/add.gif">

Some thoughts

This is a two step process:

1.  Create a theme example to prove the idea.

2.  Set a time line to fix all packages to incorporate the fix.

Keys to success:

1. Inclusion into the toolkit as an idea everyone agrees on

2. Write up Docs on how to create themes

3. Create a repo of themes one could download.

4.  Maybe make a package that creates a dummy theme package you can then use to setup a new theme.

Proposed requirements for dev time:

approx 8 hours, half writing the code and designing a theme, half writing documentation
 

 Resources

• Yahoo CSS Grids   The CSS Grids are part of the YUI LIbrary   which is BSD licensed. We include some Yahoo AJAX code in the Ajax Helper package.

Theme Manager

Created by Emmanuelle Raffenne, last modified by Benjamin Brink 29 Jun 2017, at 03:20 AM

• Last modification: 2017-06-29 03:20:12.616739+02
• Status: DRAFT

What others do 

"theme" and "skin" are often used in the same way. Traditionally a "theme" is a set of icons and/or widgets, "skin" is a color scheme. The combination of the two provides look&feel.

The common way to handle themes is to upload a zip files containing the resources that will be unzip into a specific directory of the site structure. The theme usually contains:

• a configuration file
• a collection of stylesheets
• a collection of icons
• a pair of templates: header and footer

Resources for specific modules are structured into directories. 

Joomla! 

<holycow> for joomla 1.0.x it was an xml file plus resource files which were php/html + images + css and you just upload them to a dir and click it on

 http://www.joomla.org/

Drupal

http://drupal.org/ 

moodle

 Themes can be set at different level:

• Site: applied to all pages
• User: applied to all pages, overrides the site one if set in user profile
• Session: applied to all pages, overrides the site and user one
• Course: applied on the course, overrides site, user and session one for the course only. set in the course profile

The priority of the themes can be set/changed using a variable of the configuration.

The theme can be defined as being a "stand-alone" one or extending another one

References:

• http://docs.moodle.org/en/Theme_settings
• http://moodle.org/ 

ATutor 

http://www.atutor.ca/ 

What is an acs-theme?

References are based on OpenACS version 5.4.2 and early 5.5.0d 

In OpenACS context, a "theme" can be defined as a composition of:

• templates: for the organization of the information
• stylesheets: for layout and skinning
• icons: graphic representation of common actions and entities (see acs-kernel.common_* message keys)
• widgets: WYSIWYG HTML editor ???

Templates

This is a list of the templates that can be set using parameters: 

• master template: acs-subsite, section Main
  • DefaultMaster
• list template:
  • acs-templating, section Main:
  • • DefaultListFilterStyle (misnamed since it's not a style but a template)
    • DefaultListStyle
  • acs-subsite, section Main
    • DefaultListStyle
• form template:
  • acs-templating, section Main
  • • DefaultFormStyle
  • acs-subsite, section Main
    • DefaultFormStyle
• others:
  • acs-subsite, section Templates
    • LoginTemplate
    • UserHomeTemplate
    • UserInfoTemplate
    • UserNewTemplate
  • acs-subsite, section Main
    • EmailConfirmTemplate

Stylesheets

Currently stylesheets are hard-coded. A few individual applications (e.g. calendar, forums) have their  own stylesheets.

Icons

Same. Icons are hard-coded. 

Widgets

The HTML editor is set in acs-templating using the following parameters:

• RichTextEditor
• XinhaDefaultPlugins

Scenarios 

Facebook-like site (holycow) - per subsite

Users with specific needs - per user

Requirements

*** ROUGH DRAFT of random ideas ***

- managing icons relies on a strict convention for paths and filenames

- a theme can be an extension of an existing one (default one or not), e.g.: high contrast
- a theme can be a "stand-alone" one

- should be able to specify CSS and their order
- should be able to specify the type of the CSSs (alternate or not) and others attributes (media)

- a package should be able to register its individual CSS for one theme

- a skin can be paired to a theme, in this case it should include the image directory with the icons files.

- the theme can be chosen at subsite level
- user must be able to choose her theme, in this case it overrides the subsite one

- theme-manager should provide or comes along with a default theme 

Site Nodes Proposal (Draft)

Created by Lee Denison, last modified by Benjamin Brink 29 Jun 2017, at 03:19 AM

State of This Document

This proposal should be considered a rough draft as it has not yet been reviewed by any core team members.  The response::* api has been renamed and moved to a separate proposal (templatehead).

Goals of this proposal, ie. why change site nodes?

I believe the changes in this proposal would:

• Allow more flexible use of the url space to facilitate a site wide approach to CMS type applications.
• Allow better and simpler integration for applications with a data driven url space (eg. wiki, form builder).
• Support better models of code reuse within OpenACS.
• Help relieve the burden on the overloaded concept of a subsite.

Suggested Changes

Abstractly, the changes I'm suggesting are:

• Allow site nodes to have multiple root nodes.  Site nodes are currently constrained to be a single tree.  Clearly the main site tree would need to be easily identifiable.  This would allow applications to re-use the existing site_nodes datamodel to represent their own data driven url spaces.  This would also allow different hostnames to correspond to different root nodes.
• Allow any object type to be mounted at a site node (the site nodes datamodel already allows any object type to be mounted but beyond a certain point the request processor assumes the mounted object is a package).  Or put another way, the principal purpose of a site node would be to select a function to handle the request rather than a package object.  The current control flow for handling packages would become a function invoked in this way.
• Allow parameters to be associated with site nodes.  This would allow concept such as the DefaultMaster to be moved out of acs-subsite as well as allowing generic action code to be parameterised in a specific location.
• Already Implemented: Lazy Caching of site nodes. Site nodes are lazy cached, meaning they are loaded from the database once they are called / accessed for the first time instead of during startup. This considerably brings down the time needed for starting dotLRN.

I have implemented the above ideas in a copy of the site_nodes datamodel called 'locations'.  Together with dynamic types I've used locations to create dynamic wizards and a data driven form builder which could be considered proofs of the concept.  

Implementation Detail

Multiple Root Nodes

This can be achieved by treating site_nodes at depth 1 as root nodes; ie. the children of the current singleton root node would be root nodes in their own right. 

The overall root site node is created during the kernel datamodel installation.  The URL space for the main site, as we know it currently, would be created as a child of this root node with its root (at depth 1) being assigned an acs_magic_object.  I propose the magic object be called 'default_site_root'.  The root of the site nodes tree would therefore look something like this:

Despite the lack of a specific 'node_id' or 'url' option in some cases, the site_nodes::* api is designed to allow you to identify a site node by either its url or node_id.  I would propose that functions which currently accept a node_id would carry out their function on the specified node regardless of which tree the node belongs to.  Functions which accept a url parameter to identify the site_node would be given an optional 'root_id' switch which defaults to the 'default_site_root' magic object.  The 'root_id' switch would allow you to look up a node by url in a different tree.

By default all hostnames are considered mapped to the 'default_site_root' node.  In this proposal the host_node_map could be used to assign hostnames to alternate root nodes.  Although I don't think their is enough support in the toolkit as a whole for templates/packages/objects which appear simultaneously at different paths below a hostname, this aspect of the host_node_map would continue to function as before.

Method Mapped URLs

Many MVC frameworks incorporate the idea of mapping handler functions (or controllers if you like) to urls - this much is pretty well understood.  Exactly how a particular method should be selected for given URL may be a matter for debate.  For example, some members of the core team have discussed with me the idea that the selection should be based in part on the data type of the object mounted on a site node.  Personally, I would go for the simplest option: store the name of the function to call in the site node.  I'll leave this part to be defined after there has been more discussion.

Site Node Parameters

These would be implemented using a fairly standard skinny tables approach similar to package parameters.

Impact On Existing Code

Currently I believe the code that would be affected by these changes amounts to:

• Site nodes api and caching code: would need to be updated to understand multiple root nodes.  A small number of changes are required to remove assumptions of apm_packages.
• Site map admin pages: would need to be updated to understand that objects other than packages may be mounted.
• Any code which assumes only apm_packages are mounted on site nodes.