Search · Index

Time/Topics Planner for dotLRN Courses


.LRN Blocks View is an additional View to .LRN Communities or Classes.

The Blocks View works by integrating all kinds of activities or resources of a community to a simple interface where everything is treated by the object id no matter what the object type is, and creating a new behavior to the activities according to the object type.

The new interface becomes the Community Home and is organized by blocks, there are currently 2 formats for the blocks:
  • Weekly Format
    • Each block represents a week, the weeks start to count the day the community starts, this value is set in the Course Settings of the Blocks View.
    • The current weeks is highlighted.
  • Topics Format
    • Each block represents a topic, all the activities and resources in this block are related to the topic, in this format the start date of the community is not relevant.
    • This format lets the teacher selects the current topic and highlights that topic automatically until it is deselected or another topic is selected, only one topic can be selected at a time.

This option is available for all communities inside the dotlrn-admin-portlet, there's a link to enable/disable this view, when the view is enabled a default empty block is created inside the community (this initial block it is always shown on top with no format) and it automatically mounts the packages needed (evaluation, assessment, forums, content, xowiki, chat) on the community.

Course Settings

In the Course Settings of the Blocks View we can set:
  • the number of blocks, if the number of blocks selected is greater than the current blocks, the extra blocks needed are created, if the number of blocks selected is lower than the current blocks the rest of the blocks are simply not displayed but never deleted.
  • the start date, this is used to set the start day for the weekly format.
  • the format, weekly or topics.

Blocks Basics

To add objects to a block there is a section inside each block where we can select the type of activity/resource we want to add and it lead us to the specific interface of that object type to create a new object or we can go to choose an existing activity from an interface showing all the available activities.

Each block has the following options:
  • Add a summary, this is a small text that we can add to be shown on top of the block to describe the block's content.
  • Show/Hide, we can choose which blocks we want to make available for students.
  • Move, the blocks can be ordered by using a drag n drop option to move them or doing a manual move by moving the block one position at a time.

Blocks Objects Basics

Each object inside a block has the following options:
  • Show/Hide, we can choose which object we want to make available for students.
  • Move, the objects can be ordered inside the same block or moved to a different block by using the drag n drop option.
  • Indent, the objects can be indent right or left, this is just for visual purposes and it has no side effect on the behavior of the objects.
  • Edit, this link lead us to the specific edit interface depending on the object type.
  • Delete, this link deletes the reference of the object with the block and if the object is not referenced by another block it deletes the object as well.

Technical Specs

The relations between all the packages integrated with blocks are handled by using callbacks, this callbacks are declared in the blocks context and the implemented in each package context.

The callbacks used are:
Specific callbacks: These callbacks need to be implemented for each package  because it must return the url for different actions on an specific object type.
  1. search::url
  2. planner::edit_url
  3. planner::delete_url
Standard callbacks: These callbacks are implemented once because there's no difference in the code needed for all packages.*
  1. planner::extend_form
  2. planner::insert_object

* The only package with a different implementation for the standard callbacks is the file-storage, the objects of the file-storage cannot be treated only with the object_id because there are different types of objects (url, file or folder) and to be able to choose a file we might need to navigate inside some folders, so in this case the value for the block id is passed in the cookies and the cookies are validated by the parameter return_url.

A New Package

A new package was created based on xowiki called "pages" to accomplish the integration of xowiki with the blocks view, xowiki is not a usual package so it was not possible to add the callbacks in the same way as the rest of the packages, a lot of procs needed to be changed and to avoid adding too much code to xowiki we created an independent package.  This package requires xowiki as it uses all the xowiki classes and procs.

This package works just like xowiki but using a different policy to let the users only work with ::xowiki::Page and ::xowiki::PlainPage, adding new pages can be handled only from the blocks interface because it needs a block to associate the page with. The package has a callback "after-mount" to set the permissions to not inherit from parent and only swa can admin that package.

Navigation Bar

The blocks view provides a navigation bar in the master section (only inside of the community), this bar show all the objects inside the blocks on that community and you can go to any object on any block. If you're inside an object page, the navigation focuses on that object (this is done by sending a parameter to the master with the object_id) and enables the navigation to the next and previous object (if possible).


This .LRN Planner went through scalability tests because it has it's own data model which links objects from all the other resources tables, if this is used as every single course home organizer it could become slow know that needs to get specific information from different tables for every object. 

The solution for this matter was to group all the activities of a course for a specific type, get the information by groups and leave it in aolserver's cache, this involves a lot of extra code to keep the cache up-to-date, this is completely handled to make the planner a powerful solution for every course in .LRN.

Project Documentation

This paper was presented in the 7th OpenACS/.LRN Conference, you can check out the conference paper.

How to Install

Works on:
Postgresql 8.2.x +
Oracle 9i +

dotlrn 2.4.1
xowiki 0.106.1
xotcl-core 0.100
ajaxhelper 0.87d

Installation process:

  1. Get the following packages from branch oacs-5-4: dotlrn-all, xowiki, xotcl-core
  2. Get the following packages from HEAD: planner, pages, ajaxhelper
  3. Move to the planner-patch folder in the planner package folder and run the, this will patch all the files from other packages to integrate them with the planner new features
    1. To run the script:
      • /$path_to_planner_patch/$  sh
  4. Install dotlrn, then install xowiki, xotcl-core, planner, pages and ajaxhelper
  5. Restart the server
  6. Activate the Planner View in a course admin portlet

Release Notes

Name: .LRN Planner
Version: 1.0b (July 2009)
Developed by: Alvaro Rodriguez (Viaro Networks)

  • Full integration with dotlrn resources: evaluation, assessment, forums, file-storage, HTML and Text Pages (using the Pages package)
  • Use of aolserver cache to assure scalability
  • Weeks and topics formats available
  • Provides a completely independent course home
This is how the Planner View looks.

Technical Specs

The planner works by linking activities by calling the callbacks that have been added to other packages in the add forms to be able to link the resources from those packages to the planner blocks. The callbacks extend the form of a new object to receive the page_id to be linked to and inserts the objects to the page once it has been created in the submit section of the form.

Each callback is defined and implemented in the planner-procs, in the following way:
ad_proc -public -callback "callback_name" -impl planner
if a package needs a different implementation of a callback it should be done in the package callbacks procs in the following way:
ad_proc -public -callback "callback_name" -impl $package_key
This callbacks are used inside the page that has the form for creating/editing new in the following way:
callback -catch -impl planner "callback_name" -params...

To add a new package to the activities available in the planner, the callbacks should be added to the file(s) where the objects are created, i.e. forum-new, task-add-edit, etc.
  1. A new parameter called block_id needs to be added to the ad_page_contract
  2. The following callback should be added in a place where the form can be extended
    • callback -catch -impl planner planner::extend_form -name $form_name -block_id $block_id
  3. The following callback should be added in the submit section of the form after the object has been created
    • callback -catch -impl planner planner::insert_object -name $object_name -block_id $block_id -object_id $object_id
  4. The activity should be added to the index, select-activity and get-activities pages in the planner package, check out the existing activities sections to figure out the right way to include 
  5. Depending on the activity, other lines of code need to be added to keep the consistency with the use of aolserver's cache, to keep it up-to-date with objects add/edit/delete actions.

The script added to the package to patch the rest of the packages was generated with diff between the packages from clean oacs-5-4 and modified oacs-5-4:
diff -crNB ~/oacs-5-4/packages/$package_name ~/custom-oacs-5-4/packages/$package_name

This work was done in collaboration with Innova - UNED.

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

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 , hstore , includelets , install , installation , installers , install-ns , javascript , libthread , linux , monitoring
No registered users in community xowiki
in last 30 minutes