Time/Topics Planner for dotLRN Courses

Introduction

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


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.

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).

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.

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