Search · Index

Weblog

Filtered by date 2017-04-20, 1 - 10 of 13 Postings (all, summary)

OpenACS/.LRN for Debian

Created by Héctor Romojaro, Stefan Sobernig, last modified by Gustaf Neumann 20 Apr 2017, at 10:33 PM

 

Logo

 

Packages of OpenACS  and .LRN  are now available for Debian GNU/Linux . We hope to facilitate the adoption by novices and the infrastructure deployment by professional users, both running Debian GNU/Linux  and its derivates. Our packaging activity explicitly targets Debian GNU/Linux  stable , testing and unstable . Important dependencies are co-maintained with the Debian Tcl/Tk Maintainers .

See also OpenACS for Ubuntu.

Getting started

Please, review the section on supported distributions first.  Currently, the core packages (openacs, dotlrn) and their dependencies are included into the official Debian GNU/Linux  repositories.

Install


  1. Run:

    apt-get update

     

  2. (optional) Provide for a PostgreSQL environment: If you don't have a PostgreSQL installation at hand, provide one. You do not need to care about setting up a concrete data base. This is automatically done by the openacs and dotlrn post-install instructions. For further PostgreSQL-related set-up issue, see ...
     
    apt-get install postgresql
    
    If you run a remote PostgreSQL instance, remember to allow for access of the PostgreSQL Administrator (postgres) and the openacs/dotlrn user from machine hosting your OpenACS/.LRN installation.
     
  3. Install the core packages and follow the on-screen instructions:
     
    # OpenACS
    apt-get install openacs
    ... or ...
     
    # .LRN
    apt-get install dotlrn   

After Install

  1. (optional) To change IP address and port of the instance, please edit the file:
     
    # OpenACS
    /etc/openacs/openacs.sh
    
    # dotLRN
    /etc/dotlrn/dotlrn.sh
    
    
    
  2. (optional) To control the instance using daemontools, please install the daemontools debian packages and follow the instructions on the file:

     
    # OpenACS
    /usr/share/doc/openacs/README.daemontools
    
    # dotLRN
    /usr/share/doc/dotlrn/README.daemontools
     

To-dos

Next Steps, After Basic Installation (above)

 

People

Active contributors

  • Héctor Romojaro 
  • Stefan Sobernig
  • Avni M. Khatri
  • Carl R. Blesius


Packages status


Packages maintained by Debian Tcl/Tk Maintainers 

 

Packages co-maintained by OCT & Debian Tcl/Tk Maintainers 

 

 

 

Prodding

Please, for getting in contact and reporting issues, consider ...

OpenACS/.LRN for Ubuntu

Created by Héctor Romojaro, last modified by Gustaf Neumann 20 Apr 2017, at 10:32 PM

Packages of OpenACS  and .LRN  are now available for Ubuntu Linux . We hope to facilitate the adoption by novices and the infrastructure deployment by professional users, both running Debian GNU/Linux  and its derivates. This is an on-going effort. Beware, our packaging activity explicitly targets Ubuntu Linux  10.04 LTS (Lucid Lynx) and further versions. Important dependencies are co-maintained with the Debian Tcl/Tk Maintainers .

See also OpenACS for Debian.

Getting started

Please, review the section on supported distributions first. Currently, the core packages (openacs, dotlrn) are included into the Universe Ubuntu repository.

Release packages for Ubuntu 10.04 and Further


  1. Run:
     
    apt-get update
  2. (optional) Provide for a PostgreSQL environment: If you don't have a PostgreSQL installation at hand, provide one. You do not need to care about setting up a concrete data base. This is automatically done by the openacs and dotlrn post-install instructions.

     

    apt-get install postgresql
    
    If you run a remote PostgreSQL instance, remember to allow for access of the PostgreSQL Administrator (postgres) and the openacs/dotlrn user from the machine hosting your OpenACS/.LRN installation.
     
  3. Install the core packages and follow the on-screen instructions:
     
    # OpenACS
    apt-get install openacs
    ... or ...
     
    # .LRN
    apt-get install dotlrn 
     

After Install

  1. (optional) To change IP address and port of the instance, please edit the file:
     
    # OpenACS
    /etc/openacs/openacs.sh
    
    # dotLRN
    /etc/dotlrn/dotlrn.sh
    
    
    
  2. (optional) To control the instance using daemontools, please install the daemontools ubuntu packages and follow the instructions on the file:

     
    # OpenACS
    /usr/share/doc/openacs/README.daemontools
    
    # dotLRN
    /usr/share/doc/dotlrn/README.daemontools
     

 

People

Active contributors

  • Héctor Romojaro 
  • Stefan Sobernig
  • Avni M. Khatri
  • Carl R. Blesius


Packages status


Packages maintained by Debian Tcl/Tk Maintainers 

 

Packages co-maintained by OCT & Debian Tcl/Tk Maintainers 

 

 

 

Community packages maintained by OCT

Prodding

Please, for getting in contact and reporting issues, consider ...

for developers

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:44 PM

OpenACS for developers

Features

Besides the quality components of Openacs (See: en:openacs-system), OpenACS has these enterprise-quality features for developers:


will be pulling in docs from here: http://openacs.org/doc/acs-package-dev.html and http://openacs.org/doc/acs-plat-dev.html

Integrated Development Environments (IDE)

These text editors are commonly used when coding on OpenACS:

Bibliography and Credits

See en:doc-credits.

Marketing Team

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Apr 2017, at 06:31 PM

OpenACS/.LRN Marketing Team 

Goals

The Marketing Team works to improve adoption and recognition of OpenACS including .LRN and other OpenACS projects.

Team Members

Team members are those people who are want  to be on the team or are proposed to be on the team, and willing to contribute to it, those members will be selected and ratified.  Terms and roles and responsibilities will be determined by the Marketing Team.  This process will be reviewed in a year to see if a more formal process is needed.

 

The Decision Making Process

Goals

  • Make it easy for motivated people to make decisions and implement them with minimal overhead.
  • Give the elected OCT and .LRN Board oversight over decisions without requiring too much time. 

Process

  1. All members of the  OCT, .LRN Board and Marketing Team subscribe to a designated Forum, email list or Wiki page.
  2. Members of the Marketing Team are responsible for reaching out to the appropriate people while making major decisions. Depending on the decision this includes the greater OpenACS community, the OpenACS, .LRN Board and/or membership, and the .LRN Leadership committee.
  3. When an individual believes he has done an appropriate level of communication and consensus building on a decision he posts it in the designated place.
  4. If no one objects or calls for a vote the decision is confirmed in 2 weeks.
  5. If people agree they need take no action; however if there is disagreement or concern, any member of the Board, OCT or Marketing Team may “Call for a Vote” on any decision posted to the decision forum within 2 weeks of the post.
    • The .LRN Board should only call for a vote on things that relate to .LRN brand or dotlrn.org and only the .LRN Board members vote.
    • The OCT should only call for a vote on things that relate to the OpenACS brand or openacs.org or have a technical component that relates to the core (training materials might be an example). In an OpenACS related issue only OCT members vote. The role of the OCT maybe temporary as its charter was to deal with technical issues. However it is currently the only elected body of OpenACS. We will revisit this issue in a year.
    • In the rather unlikely situation where the distinction between OpenACS and .LRN is not clear and its controversial issue then either should call for a vote and both organizations should try to come to agreement. 
  6. A decision is upheld with 2 Yes and 0 No’s or a 2/3 majority of all members of the appropriate organization (either the OCT or .LRN Board).  This is usually 5 people.

Informal description of the process

If you have an idea you'd like to implement, discuss it with people who care, post in OpenACS and/or talk about it in an online or meeting or conference. . After you have listened, post your decision Then implement it.  Mostly we all want the same things and we need action.  The OCT and .LRN Board vote is available as an oversight and in those hopefully infrequent times when there is significant dissent.

This is an interim  process 

This process is based on a discussion at the Vienna Conference. There were many different ideas about whether the Marketing Team should be directly elected or report to the current elected boards. There was also discussion about two teams (OpenACS and .LRN) versus 1 team.  This process is the simplest we think could work and our intent is to revisit these questions in a year (or less) and refine the process as needed.

The Marketing Team will be formed when both the OCT and the .LRN Board approve its formation.

 

Source control

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:22 PM

 
A Source Control system keeps track of all of the old versions of your files. It lets you recover old files, compare versions of file, and identify specific versions and groupings of files such as for controlled deployment.

the OpenACS reference platform and the OpenACS.org repository (where you can get patched and development code in between releases) use cvs.

This is a place to add notes about other source controls and services used by the community..

 

Guidelines

First READ the official cvs rules http://openacs.org/forums/message-view?message_id=185506 

These rules apply whichever source control tool OpenACS is using at the time. As of this writing, we are still using CVS.

 

  1. Don't mix bug fixes and new work
  2. Don't commit code before it is tested in a clean environment (new working copy)
  3. If possible, have someone else test your fix
  4. Branch when necessary, don't be afraid of it (but ask OCT first)

1. Don't mix bug fixes and

  • Be liberal with working copies. If you need to merge custom code into OpenACS, checkout a new working copy. Don't be stingy. Disk space is cheap. This prevents many problems by reducing accidental commits.
    • bottom line: don't mix bug fixes and new work! If you have a checkout of OpenACS you are developing some new package or feature for an existing package, and you run into a bug, fix the bug in a clean checkout of OpenACS. This is the only sane way to make sure you 1) actually fix the bug and 2) don't commit other changes that don't pertain to the bug fix.

2. Don't commit code before it is tested in clean environment

  • Review your changes before committing. If possible ask someone else to look. Do a cvs -qn update to see if the commit is not changing any files you did not expect. Use cvs diff to compare your changes to the respository.
  • So for committing code back to OpenACS from your local repository you should have 2 copies
    • 1) your local code
    • 2) a working copy of OpenACS HEAD
  • You should make all changes in the working copy and fully test it, running automated tests and checking to make sure you did not accidentally change something or add in client specific  code that is not reusable by OpenACS.

3. If possible, have someone else test your fix

  • this should be self-evident, a second pair of eyes always helps to find something you missed.
  • if another person is not possible, write an automated test, in fact, write one anyway! 

4. Branch when necessary, don't be afraid of it (but ask OCT first)

  • Large projects should be done on a branch. This is a pain with CVS, but it is the only sensible way to do this. Examples include any project that will span a major release cycle. It is the responsibility of the person doing the branch to keep up to date with HEAD and to merge and have the code tested. It is sensible to test in a working copy BEFORE committing the code.

Ideas

Here is my heretical idea. I think we must have another branch. Here is how it would work.

1) developer has a working copy.

2) develop commits code to HEAD

3) code is merged to testing branch

4) code is tested

5) code is moved to release branch

Yes, this is extra work. I believe it is worth it. It is a serious pain with CVS. We started using svnmerge.py for Subversion on our private repository and I saw immediate improvements in process. In this case I think having a well defined process AND tools that facilitate the process are key. OpenACS lacks a well defined process, discipline, and tools to facilitate the process. I believe we need to work harder to define this process and I would like to collaborate with the community on this.


 

Aliases at CVS

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 20 Apr 2017, at 06:20 PM

Useful aliases for cvs.openacs.org:

  • acs-core *
  • dotlrn-all *
  • dotlrn-extras *
  • contrib
  • project-manager-all
  • xotcl-all
  • dotngo
  • dotwrk

 * These aliases are controlled by OCT and .LRN honchos groups, the packages that belong to these aliases are the ones that are maintained by both groups. They are not to be changed unless approved by OCT and / or .LRN technical committee.

Below the packages details for each alias:


 

##################################################################
# OpenACS Core
##################################################################

acs-core -a openacs-4/packages/acs-admin
openacs-4/packages/acs-api-browser
openacs-4/packages/acs-authentication
openacs-4/packages/acs-automated-testing
openacs-4/packages/acs-bootstrap-installer
openacs-4/packages/acs-content-repository
openacs-4/packages/acs-core-docs
openacs-4/packages/acs-developer-support
openacs-4/packages/acs-kernel
openacs-4/packages/acs-lang
openacs-4/packages/acs-mail-lite
openacs-4/packages/acs-messaging
openacs-4/packages/acs-reference
openacs-4/packages/acs-service-contract
openacs-4/packages/acs-subsite
openacs-4/packages/acs-tcl
openacs-4/packages/acs-templating
openacs-4/packages/ref-timezones
openacs-4/packages/acs-translations
openacs-4/packages/intermedia-driver
openacs-4/packages/openacs-default-theme
openacs-4/packages/notifications
openacs-4/packages/search
openacs-4/packages/tsearch2-driver
openacs-4/ChangeLog
openacs-4/license.txt
openacs-4/readme.txt
openacs-4/bin
openacs-4/content-repository-content-files
openacs-4/database-backup
openacs-4/etc
openacs-4/log
openacs-4/tcl
openacs-4/www

##################################################################
# .LRN aliases
##################################################################

dotlrn-all -a acs-datetime acs-events
attachments bulk-mail calendar faq file-storage
forums general-comments news lars-blogger
weblogger-portlet rss-support trackback oacs-dav
xml-rpc categories dotlrn dotlrn-syllabus new-portal
profile-provider user-profile bm-portlet dotlrn-bm
calendar-portlet dotlrn-calendar dotlrn-portlet
dotlrn-dotlrn faq-portlet dotlrn-faq forums-portlet
dotlrn-forums fs-portlet dotlrn-fs news-portlet
dotlrn-news static-portlet dotlrn-static
dotlrn-homework dotlrn-weblogger evaluation
evaluation-portlet dotlrn-evaluation assessment
assessment-portlet dotlrn-assessment theme-selva
theme-zen dotlrn-random-photo random-photo-portlet
views

dotlrn-extras -a lors lorsm lorsm-portlet dotlrn-lorsm
photo-album photo-album-portlet dotlrn-photo-album
survey-portlet dotlrn-survey survey chat
dotlrn-chat chat-portlet xotcl-core imsld
imsld-portlet dotlrn-imsld

##################################################################
# Project Manager aliases
##################################################################

project-manager-all -a calendar acs-events acs-datetime
acs-mail-lite categories logger
project-manager general-comments
organizations


##################################################################
# xoTCL Stuff + required
##################################################################

xotcl-all -a xotcl-core xotcl-request-monitor xowiki categories
acs-events acs-datetime file-storage oacs-dav
rss-support general-comments

 

 

 

 

Assessment Admin UI

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Apr 2017, at 06:17 PM

TODO LIST

  • Update this page with the latest work
  • Carl will fill in here... 

 The current UI is very confusing and cluttered.

Our vision of a final UI is that a assessment creator would pick a type of assessment he wants and the site will set all defaults appropriately for it. However, the first attempt to do this was a failure so we are working on an incremental approach that we think will provide value with minimal effort. Our intent is that later we move to an even friendlier UI.

 Incremental Improvement Vision:  The current user experience is: every time you create anything you are confronted by many many choices, most of which you can ignore. Similarly all the admin pages have many repeated buttons and its not clear when you want to do what.  Thus our goal is:

  • Creation pages are very very simple and useful defaults are set for everything.
  • Objects then have one button to an Edit page that has all the complex things you can do with the object.

Related Pages:

 Notes

Screenshots

These are screenshots of the work in progress.

 

Simplified quick assessment creation form. 

 

One Assessment Admin Page 

 

One Section Admin Page

 

 

 Add a question page.

First the original question form:

Now the new form. The question creation process used to require filling out 3 forms. We compressed it to one form by removing unused settings, and making intelligent default decisions. Some more work needs to be done. Assessment has a huge amount of complex features and it is not clear how they are used together to create a certain type of assessment. It is clear that all of the settings rarely need to be used together.

 

Assessment Section Display Types

Created by Dave Bauer, last modified by Gustaf Neumann 20 Apr 2017, at 06:16 PM

 

Big Picture

 We are not 100% sure that we understand everything a display can or should do.

 What is clear is that:   The assessment author should be able to pick from the predefined list of display types.

We think the display type is a first step towards a UI that lets you pick a type of test/survey/quiz etc. and then sets sensible defaults. But right now its pretty confusing.  It doesn't seem to make a lot of sense as to what is controlled by the display type and what is a setting for a section.

Current Plans
We want to reorganize the display type attributes and the section functional attributes to make more sense. 

Display types currently control some display attributes of an assessment section. Right now an assessment author can create a new display type which exposes confusing and complex attributes such as a chunk of ADP code to display the assessment. Because it can involve ADP code we are assuming at this point that creating a new display type should be done by a site-wide admin.  So we intend to restrict access in the UI to creating display types.

Right now display types to be specific to the package instance level but its not clear that is the desired behavior, however we do not have immediate plans to change it. 

Display type refers to the style of display. Right now it also controls the number of questions per page. This seems wrong, Number of questions per page, is a functional attribute and should be set per section. The number of questions should not be tied to how the questions are formatted. An assessment author should be able to use any number of questions on a page with any display type.

Future thoughts: (we are not currently funded to implement these ideas)

Recently the default adp template for an assessment form has been rewritten with semantic HTML that should be suitable for most display types. The visual design can be changed with CSS. This leads me to believe that display types should evolve into CSS style declarations instead of ADP code.

Right now display types are per package instance. In general we'd want site wide display types that can be used by any assessment author in any assessment package instance. For example, with dotlrn, each class has a separate assessment package instance, but the display types may be reused across the whole site.

 

 

One Assessment's Administration Page

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Apr 2017, at 06:15 PM

url stub: /assessment/asm-admin/one-a?assessment_id=12309

 A test example: http://mgh.zill.net/assessment/asm-admin/one-a?assessment_id=12309

Here is a new idea: Lets use a tabbed interface with the following tabs.

 Assessment Name Admin | Results | Section 1 Name |  Section 2 Name

Thus we can cut down on the really long pages and make it easy for people to move between sections.

 

Assessment Name Admin 

On the one assessment admin page add in the export and permissions we took out from the top level admin page. Display the current values of all the many configuration settings an assessment can use. Since we now have sections and questions on another page we can use the space here to show these details and let people change them one by one. I believe this will be less intimidating then the current form which seems to ask you for 20 incomprehensible decisions right up front.  Eventually we can add links to help text that would explain why you might want to use these different options.

Results

We aren't going to deal with the details of the results page right now, but in day to day operation the results are the most important most used part of the admin interface. It should be easier to get to and we should devote a full page to a UI for browsing and getting to the results you want.

Sections



 New Look would be something like

 

1. Section 1 (SEC_12312) Edit | Preview |  Triggers | Add New Section

  • Lets either use icons or words in class=button. Mixing them is not working. I think words are easier for now.
  • Search for a new section is a particular form of adding a new section. It should be an option AFTER you click Add New Section
  • Edit Display types actually edits the package wide display type. This should be done from the top level page.
  • Everything you might want to do with triggers can be dealt with after you click triggers.
  • Moving a section should be done from the Edit page. We can present a UI that lets people say exactly what section they want this section to follow. Should be easier then incrementally using arrows.
  • Delete should be an "Extreme Action" on the edit page.

Items (Questions)

items.png

 

New Look

2. Last Name  ( QUE_4551)  2 triggers Preview

Edit | Move Up | Move Down | Delete | Copy | New Question 

  • Hide the details of the question until someone clicks Preview then use CSS to display the entire question inline.
  • Searching for questions is a specific way of adding a new question so it should be an option on the new question page. \
  • Trigger administration should be an option on the Edit page. I think we need to keep a visual reminder here when triggers are defined for a question as that is a pretty important and unusual event.

We can repeat Add a New Question and then below that Add a New Section at the bottom of the page for convenience. Remove all references to searching as per above.




 

 

User Parameter Package - RFC

Created by Ryan Gallimore, last modified by Gustaf Neumann 20 Apr 2017, at 06:14 PM

There seems to be a need in OpenACS for user-defined parameters. These might include customizing a menu, personalizing a site style template, or even removing or adding includes and panels.

 Here's an initial brainstorm of possible field types:

  • Personalized text - user defined text or titles, such as the title of a personal subsite homepage
  • Turn on/off toolbar buttons
  • Color picker
  • CSS stylesheet
  • Turn on/off includes (e.g. Solution Grove homepage)
  • Change site theme (e.g selva) - is this possible?

The best part of this is that it is dead easy to add new parameters via the APM.

Please post your comments here.

Ryan Gallimore - Viscous Media

CM: What would the user facing UI for this look  like? Parameters are such a horrid UI.

I was talking to a person from the MIT media lab who works on a site for kids there. Their site allows the kids to use the CSS personalization for My Space. This means that there are all sorts of cool themes for the kids without the site owners having to program them.  T. The problem they have is that some of the themes have very very My Space specific things, like hide the 3rd table in the 4th div, which is of course quite different on their site then My Space's.  Nevertheless, this is an idea we might want to use, making out stuff compatible either My Space or another system with a wide variety of themes so we get a lot of looks for "free"

 

Daveb: what do you mean by user-editable parameters? Do you mean "preferences"? Is this for administrators or regular users.  

Ryan: by user-editable pages I mean regular users, and yes you could call them preferences, but users would  be editing parameters directly in oacs. As far as UI goes, I think the current UI for parameters would work well - perhaps with more field validation.

Maltes: There exists a user_preferences table and this is where your custom applications should store it's values. Then just write a page with form callback hooks (look at callback::contact::special_attributes::ad_form_values::contract and callback::contact::special_attributes::ad_form_save::contract respectively in /contacts/www/contact-add.tcl) which will allow the packages to extend the form with the variables they allow the user to edit. This way you only need one page e.g. in acs-subsite /pvt/edit_preferences where the user can change all his / her user_preferences, including the ones already stored in this table. Each package would then (for each parameter it wants to have a user setting for):

  • Extend user_preferences by adding the column
  • Write a form extension callback implementation
  • Write a form save callback implementation
  • Add the code that deals with the parameter's return somewhere

Obviously it would make sense for the last step to have a cached procedure "user::get_preference -name -user_id". And we should probably enforce a naming convention like "${package_key}_$pref_name" so we are not accidentally running into name conflicts on the table.

Next Page
Previous Month April 2017 Next Month
Sun Mon Tue Wed Thu Fri Sat
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 (3) 10 11 12 13 (6) 14 15
16 17 18 19 (13) 20 21 (2) 22
23 (2) 24 25 26 (1) 27 28 29
30 1 2 3 4 5 6

Popular tags

17 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , CSP , CSRF , cvs , debian , emacs , fedora , FreeBSD , host-node-map , hstore , includelets , install , installation , installers , install-ns , javascript , libthread , linux
No registered users in community xowiki
in last 30 minutes
Contributors

OpenACS.org