Created by OpenACS community, last modified by Gustaf Neumann 13 Jun 2017, at 10:24 AM
OpenACS works on most any operating system that behaves in a manner similar to UNIX. (see "Unix-like" by Wikipedia). For example: (links to features lists of OSes)
Created by Ryan Gallimore, last modified by Gustaf Neumann 11 Jun 2017, at 10:33 AM
Notes on an OpenACS wrapper for YUI
YUI Theme [Suggestion]
nlunt: A word of warning regarding YUI Loader:
While it sounds like a good idea to load only the modules that are needed, my experience has shown that there may be more benefit to loading a single gzipped file for the javascript and css portions of YUI for a total of 250K that is cached after the first load. This sounds like a lot to load for every page, however, loading just the base modules of YUI may exceed that amount because the individual JavaScript and css files for each module are not gzipped. Loading all of YUI uncompressed is about 1M, so there is considerable benefit in loading the files compressed.
Created by Byron Linares, last modified by Maurizio Martignano 07 Jun 2017, at 05:34 PM
NOTE: Currently (06/2017), the best option to get OpenACS 5.9.* running on Windows is to use the native windows installation Windows-OpenACS by Spazio IT (Maurizio Martignano).
This page describes the installation of (quite old) components based on cygwin, but might still be useful for people, that can't use Maurizio's implementation for whatever reason:
Included Software
Installer Download :
The installer is available in openacs community page.
Available versions:
Installation Instructions:
Run the "OpenACS/DotLRN Installer" called setup.exe, read the license document before continuing, the installer will ask for some information, this will be used to make the automatic installation.
There are to ways to install the components; manually or automatic
Components
Select what you want to install and click next. After the installer places all the files, a browser window will be opened and the installation have to be continued from here, if the automatic mode has been selected wait to the installation finishes. When the installation finishes restart the server and type in a web browser "http://localhost"
Access Icons:
Diagnostics
developed at the Galileo University (www.galileo.edu) by Byron Haroldo Linares Roman bhlr@galileo.edu as part of the E-LANE project (www.e-lane.org)
Created by OpenACS community, last modified by Gustaf Neumann 07 Jun 2017, at 11:02 AM
pre-release (part of the ecommerce-g2 project)
There is little consistency between packages for uploading data. Most packages do not offer an import feature. The current practice is to use the database import features directly. This also means creating small scripts or using intermediate applications to manipulate the data prior to import, and using shell commands to get the data into the right security context and location. Mistakes in the import usually have to be corrected with hand-written sql updates. A data importer likely needs to have admin level access and unix level competency, which is beyond the usual skill set required to manage a website application. A bulk-upload package would standardize and ease barriers to setting up and managing OpenACS packages.
A package that provides standardized UI and import services for bulk uploading data (tables and lists) into existing tables of other packages
see also: https://web.archive.org/web/20071007211200/http://jongriffin.com/articles/openacs-relevancy/
Exsiting ecommerce bulk upload of custom fields represents the most flexible at this point, because it handles inserts and updates, and builds the sql as well as uses the xql query files: https://raw.githubusercontent.com/openacs/ecommerce/master/www/admin/products/extras-upload-2.tcl
Perhaps a dumbed-down spreadsheet data model would work well, to allow for tables of most any number of columns or rows without having to create/expose code that modifies db tables.
DAVEB: In addition to any generic storage of imported data, I think it would be useful to support importing into specific storage tables. The easiest, best examples are the content repository, or dynamic types defined tables and views. There are Tcl apis to insert/update these tables and it makes sense to support this as well.
Don Baccus has other implementations which complement this and may provide an overall development path for a preliminary general bulk upload.
Created by Gustaf Neumann, last modified by Gustaf Neumann 07 Jun 2017, at 10:28 AM
NEW: For the impatient users there is a quick-and-dirty install guide for FreeBSD
OpenACS and .LRN are included in the current FreeBSD ports tree.
The ports are tested with FreeBSD production version 6.2-RELEASE, old stable 5.5-RELEASE and the development branch 7-CURRENT.
Installation requirements:
To install OpenACS or .LRN from the FreeBSD ports tree, follow the instructions below.
NOTICE: If you have a PostgreSQL server installed and running, skip to Section 2.
If you desire to use a local PostgreSQL server (most users do), install the server first.
We recommend using PostgreSQL version 8.2 from the databases/postgresql82-server port
# cd /usr/ports/databases/postgresql82-server # make install clean
NOTICE: As an alternative, you may install PostgreSQL server from a binary package. See Appendix B below
The plperl language is required for OpenACS/.LRN. This can be installed from the ports with the following commands:
# cd /usr/ports/databases/p5-postgresql-plperl # make install clean
To install the OpenACS/.LRN database, your PostgreSQL server must be running.
You need to enable it in your /etc/rc.conf (or /etc/rc.conf.local) by adding the following line:
postgresql_enable="YES"
After installing the PostgreSQL server, you have to initialize your data store:
# /usr/local/etc/rc.d/postgresql initdb
To start the PostgreSQL server, issue the following command:
# /usr/local/etc/rc.d/postgresql start
You can check if the server is up and running with:
# /usr/local/etc/rc.d/postgresql status
OpenACS can be installed directly from the FreeBSD ports tree, www/openacs:
# cd /usr/ports/www/openacs # make install clean
.LRN installation, www/openacs-dotlrn:
# cd /usr/ports/www/openacs-dotlrn # make install clean
NOTICE: If you want to make changes to the default configuration, the AOLserver configuration files for OpenACS/.LRN files are located at:
/usr/local/openacs/etc/openacs-config.tcl
/usr/local/dotlrn/etc/dotlrn-config.tcl
NOTICE: If you installed both OpenACS and .LRN ports, you have to change the default port of one of the installations. See the configuration files in the previous notice.
For this step, you require an installed and running PostgreSQL server (see Section 1) and installed OpenACS/.LRN (see Section 2.1)
First we need to adjust the PostgreSQL configuration (this applies for server versions 8.1.x and higher):
# /usr/local/share/doc/openacs/adjust_pgsql_conf.sh
or if .LRN was installed:
# /usr/local/share/doc/dotlrn/adjust_pgsql_conf.sh
NOTICE: You can adjust the configuration manually (standard location: /usr/local/pgsql/data/postgresql.conf)
Please see en:How_to_install_in_Postgres_8.x.
The PostgreSQL server needs to be restarted after changing the configuration:
# /usr/local/etc/rc.d/postgresql restart
Next, we can create a default OpenACS database by running the following script:
# /usr/local/share/doc/openacs/create_sampledb.sh
To create a default .LRN database, run the following script:
# /usr/local/share/doc/dotlrn/create_sampledb.sh
To make use of the automatic startup script OpenACS/.LRN has to be enabled in /etc/rc.conf (or /etc/rc.conf.local):
openacs_enable="YES"
or for .LRN:
dotlrn_enable="YES"
To start OpenACS, use the following command:
# /usr/local/etc/rc.d/openacs start
To start .LRN, use the following command:
# /usr/local/etc/rc.d/dotlrn start
Now you can login to your OpenACS/.LRN system and finalize the installation.
The default port is 8000. URL:
http://<your-ip>:<port>
After filling your e-mail address, password and other important information OpenACS/.LRN gets installed, but the server stops.
You have to start it again (see above).
To get the latest versions of the OpenACS, .LRN and other FreeBSD ports, it is recommended to update the FreeBSD ports tree on a regular basis. The easiest way to to perform this task is using the portsnap(8) command.
For documentation, refer to the following FreeBSD Handbook chapters:
Using the Ports Collection
Using Portsnap
PostgreSQL, OpenACS, .LRN and all dependent ports may be installed from binary packages, too.
This installation can be performed from a submenu of FreeBSD's sysinstall(8) command: Configure/Packages
OpenACS and .LRN are located in subcategory www, PostgreSQL is in subcategory databases.
Please send bug reports and feature suggestions to the port maintainer of OpenACS/.LRN FreeBSD ports:
Martin Matuska <mm_at_FreeBSD_dot_org>
Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 07 Jun 2017, at 09:32 AM
.LRN 2.4 will contain acs-core, dotlrn-all and dotlrn-extras packages. See Aliases at CVS for a detailed list of the packages included in those aliases.
Releases are coordinated by the .LRN Leadership Team.
Weekly technical meetings in IRC at openacs channel:
| Package | What | Who | State |
|---|---|---|---|
| Forums | Permissions. See forums for details | -- | pending |
| All | Accessibility: see forums for details | emmar | DONE |
The table below lists the bug fixed for 2.4.0
| Package/Topic | What | Who | State |
|---|---|---|---|
| Accessibility | A few improvements, see forums for details | emmar | DONE |
| Accessibility | Color of the class portal doesn't pass the luminosity contrast test (ratio = 3:1, should be 5:1 for normal text) | daveb | FIXED |
| new-portal | set default layout to theme-zen when a new page is added to a portal | donb | FIXED |
| theme-selva | fix CSS | donb |
FIXED (somewhat) I fixed the basic portal layout and decoration stuff, nothing else. If someone else cares about selva, please other css issues as you find them |
| forums | message-view expand/collapse should toggle (but it's done in javascript so the page doesn't know what the current state is) or we should just delete the options as we did in 2.3. Also the print button should disappear - print should be handled by linking the package's print.css file using media="print", with printing then handled by the browse as it is meant to be in this modern era. | vguerra | The proposed fix was incomplete (only one cookie value for all threads), feature will be removed from 2.4. Victor can fix it in HEAD for a future release if he wishes to. |
| forums | doesn't work for oracle | donb | FIXED |
| forums | forums: the "new" tag in the forums portlet lasts longer than the "bold" mark of new messages in the forum page (forum-view) | vguerra | FIXED |
| forums | when posting a message ( without previewing it ) part of the screen gets black | vguerra |
xinha problem (core) |
| forums | testing upgrade regarding the "readinginfo" new feature |
marioa emmar |
DONE |
| file-storage | file upload doesn't work for oracle | donb | FIXED (CR in core) |
| lorsm | failed because of the oracle port of views. | emmar | FIXED |
| dotlrn | sending email to new members when added to a class/club seems to be broken (no email is sent out). | nimam | FIXED |
| dotlrn | When renaming department and subject, the package instance pretty name is not edited so the old name still appears in the breadcrumbs | morals | FIXED |
| imsld | error when applet added to a class (root folder missing) | emmar | FIXED (CR in core) |
| imsld |
merge version from 5.3 to 5.4 |
derick | DONE |
| assessment | use form builder where it's possible and finish html 4.01 strict validation afterwards | emmar | DONE |
| chat | missing upgrade script (from downgrade between 2.3.0 and 2.3.1) | emmar/avni | FIXED |
| sending email | check and test with the new acs-mail-lite send proc (bulk-mail, forum, evaluation, imsld, etc.) | emmar | DONE |
| breadcrumbs |
Usability:
|
emmar | DONE |
| lorsm |
This addition cvs diff -r 1.5 -r 1.6 lorsm-create.sql Needs an upgrade script |
daveb | DONE |
Others:
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 07 Jun 2017, at 09:28 AM
After the nomination process, the current elected board:
(1 year term: 1/nov/2006 - 31/oct/2007)
Check the dotLRN governance.
Contact the board: board @t dotlrn dot org.
Created by Olga C. Santos, last modified by Gustaf Neumann 06 Jun 2017, at 11:53 PM
.LRN supports several educational standards in the following packages:
Both Assessment and LORS are part of dotLRN 2.2.0 and IMS-LD and IMS-Enterprise can be downloaded via the APM package manager.
Last modified: 2017-06-06 23:53:48.516768+02
Created by Robert Taylor, last modified by Gustaf Neumann 06 Jun 2017, at 09:23 AM
This is a very interesting website with a lot of JavaScript examples: http://www.javascripttoolbox.com
Of particular interest is the JavaScript table sorting library that could be used in a few OpenACS based apps: http://www.javascripttoolbox.com/lib/table/index.php
Created by Dave Bauer, last modified by Gustaf Neumann 02 Jun 2017, at 02:29 PM
This describes the discussion for TIP#120 https://openacs.org/forums/message-view?message_id=1482643
APM Packages are all of the same acs_object_type of 'apm_package'.
I propose creating an acs_object_type for each package type as a subtype of apm_package.
This would allow for a hierarchy of package types. The most common example we might think of is dotlrn. The dotlrn package could be a subtype of the subsite package. This would allow an easier way to determine if a package takes on the role of a subsite type package and it could greatly simplify all the code that has to be special-cased to determine if dotlrn is installed.
This would also allow simplification of the case when a new package is created to customize the user interface of another package. For example, many people would like to customize the forums package, to change the style of user interface. If we had a custom-forums package type that was sub-typed from forums, we could have a simple and consistent mechanism to defer pages to the parent package type for handling. This would allow much easier reuse of pages and would make it very simple for local customizations to be handled safely without worrying about accidentally adding custom code back into OpenACS.
The immediate goal of this work is to make the dotlrn package a subtype of the acs-subsite package. I have done preliminary work to turn dotlrn communities (groups) into application groups of the dotlrn package also. This should make it easier to do an upgrade to an existing dotlrn install that will support subsite based dotlrn.
Previous work includes the https://openacs.org/api-doc/proc-view?proc=subsite%3a%3apackage%5fkeys subsite::package_keys procedure. This basically is a hard coded list of packages that fulfill the subsite role. Defining children of a subsite object_type would allow greatly flexibility and use the existing features of the toolkit.
Steps to implement
1) Make a new object_type for existing package_types when a new package type is created. Default is subtype of apm_package.
2) Add parameter to package create code to specify package super-type
3) Add tag to info file super-type which is optional and will default to apm_package. This tag will have the same behavior as requires element so Tcl libraries are loaded of the super-type.
4) Add attribute to apm_package_types for inherit_ui_p to specify if URL resolution will go up the package type hierarchy.
5) Update apm_paramaters to support setting parameters for the super-type package parameters up the package type hierarchy. Allow sub-typed packages to override the default value of an inherited parameter.
6) Fix package loading to load Tcl libraries in package dependency order.
Comments by Don Baccus:
Let's think about UI issues for a moment ... I have an idea to toss out
Currently, abstract URL resolution works like this:
1. If a file or template at [acs_root_dir]/www/${url_path} exists, return it
2. If a file or template at [acs_root_dir]/packages/[ad_conn package_key]/${url_path} exists, return it
3. 404
We can extend this if we allow package sub-typing ...
replace 2 with ...
2. set package_key [ad_conn package_key]
2a. while no file exists at [acs_root_dir]/packages/$package_key/$url_path do
2b. if parent type is apm_package, break, else set package key to parent type's package key
2c. od
2d. if exists - return file or template
In other words, allow for the inheritance of parent package UI.
Often, of course, this isn't always desirable, so an apm package type would want to have a "don't inherit UI" attribute. You'd do this, for instance, if you were going to brand new UI for an existing package. Say ... a portlet.
Inheriting the UI though allows for some things. For instance, dotlrn could be mounted at /, no need to mount an acs-subsite instance at all as is done now because its UI would already be available (assuming dotlrn was derived from acs-subsite).
How would this impact performance? Not at all, if the request processor's performance mode is enabled, and when it's not, who cares?
Comments by Gustaf Neumann:
Defining package types as acs-object-types and allowing sub-typing/sub-classing for packages using these is a good idea. As presented at the OpenACS conference in Guatemala, xotcl-core and xowiki support this already since about a year. So is it possible to define the s5-package by reusing xowiki in a few lines of code. Other examples were presented by Victor Barrios (mashup) or Stefan.
Subtyping acs-object-types is just the first step, the (desired) implication are something which might need more discussions. Some changes are desirable for the package manager or the request processor.
Note, that in the xo* packages, it is not only the case that packages are object-types, but that package instances are objects (actually xotcl objects), which provide the package instance specific context for a request. Package instance objects are initialized at the begin and deleted at the end of a request.
Below i will use the term "reused package" for the superclass (the more general package) and the term "specialized package" for the subclass (the more specific package, inheriting from the superclass package).
Here are a few items from my experience:
For the three issues, the xo* packages use the following strategy:
An example for the redirector is https://raw.githubusercontent.com/openacs/s5/master/www/admin/index.vuh
The approach with index.vuh works quite well, since physical existing files override the virtual (index.vuh) redirect. So, all per-request files in www/* in the specialized package, which should be different from the reused package, can be put to the www/* directory of the specialized package (e.g. s5). Not sure, how this approach works over multiple specialization levels.
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
