Forum OpenACS Development: Proposal to Extend dotlrn-catalog
please visit the wiki page of dotlrn-catalog under
http://www.openacs.org/xowiki/pages/en/dotlrn-catalog
I have written a proposal on how to transparently extend dotlrn-catalog in order to make it usable for different scenarios and institutions.
Any suggestions and comments are welcome. Please use the wiki for this purpose.
Also note that xowiki for IE seems to be broken. No page is displayed even though if you look at the source code of the page there is content. Therefore use any other browser.
=======================================
Proposal To Extend dotLRN Course Catalog
=======================================
Author: Nima Mazloumi
After talking to Carl and Dave I would like to propose the following extensions to dotlrn-catalog: Please forgive my poor englisch and feel free to contact me for further questions.
Extension technique
=======================================
In order to keep dotlrn-catalog simple all new extensions should be realized as sub types of the object type dotlrn_catalog. Thus we don't introduce new attributes to the dotlrn_catalog table. Instead the new sub type shall provide it's own table and attributes.
In order to support several sub types dotlrn-catalog has to be modularized in a way that those fragments specific to a type so-to-speak infused in the right way. For this two concepts shall serve as a solution:
- usage of inclulets for adp pages and
- usage of socalled user-exists for the tcl code.
Includelets
---------------------------------------------
Includelets are the standard way to include adp files within others. The characteristic in this case is that the adp file included is determined by the given sub type used. For this purpose dotlrn_catalog will contain a supfolder lib with serveral subfolders named exactly by the sub type name. Depending on the given type right system will select the right includelet and render the view.
User Exits
---------------------------------------------
In this case the tcl files have to be extended transparently depending of the given sub type. For this purpose we would like to suggest the usage of callbacks. Depending of the extension form (exclusive or composition) either the callback directly or an implementation for a given type is called to extend the behaviour of the package.
Behaviour at runtime
---------------------------------------------
The default behaviour of dotlrn-catalog will be how it is right now. Administrators are able to create new course items, associate assessments to them and link them to dotlrn communities. The only difference will be how the pages are composed. With the above propsed solution the default installation will only know the object type dotlrn_catalog and therefore only include includlets for this type and also only call callback implementations for this type. This solution will not require any changes to the datamodel.
To achieve this solution forms, lists and type-specific fragments need to ge generated dynamically depending of the object type. You can see it partially implemented in the course-add-edit file in the current dotlrn-catalog package.
To achieve this dotlrn-catalog uses already now the new CR TCL API.
Activation of new types
---------------------------------------------
This is done via a new package parameter called SupportedTypes which will contain the list of available types to the system. The default version of dotlrn-catalog will only know the type dotlrn_catalog. In order to use the other types as well more types must be entered to the list.
Thus at runtime OpenACS will check for the available types and make them available to the installation.
Suggested Extension to dotlrn-catalog
---------------------------------------------
The Unversity of Mannheim has implemented a package called groups which has be used productively in Mannheim for almost one year and which is used by professors to organize the registration process for their courses.
Next to standard attributes like group name, start date, end date, description and the like, which is also available in dotlrn-catalog for courses the packages provides attributes like
- maximal members - to limit the size of the group depending on ressource restrictions like seats ...
- minimal members - to decide whether the course will take place at all or not
- registration begin - when the registration process will begin
- registration end - when the registration will end
- approval required leaving the group
- approval required for entering the group
- allow waiting list for students rejected
- white list, black list - number of choices the student has to make for courses interested to join or not (see below for explanation)
- can student change his choices during the registration period
Thus an administrator can create a new group type with the above characteristics and let the system take care of the registration process. For this purpose the administrator can select from different join policies. The default policy is the First-Come-First-Served which corresponds to the open policy. The second one is the requires approval which speaks for itself. The third and new policy is by preferences.
This policy allows students to choose from a list of 1 or more available parallel courses. The idea behind this is that often the same course is given during a semester on different days and hours during the week in order to keep the classes small. Since some of them are more appealing than others - maybe one is on monday morning or the other on friday evening - the preffered ones the to explode while other courses are visited sporadically. To solve this problem we don't let the students join direclty a course. Rather we allow the student to indicate which courses he can imagine to join and which not. This we call white and black list. Once the registration process is over. We let the system automatically distribute the students to the courses taking in mind the size restrictions of the course as well as the choices of the students.
In order to integrate this in dotlrn-catalog we propose the creation of a new sub type of dotrn_catalog called dotlrn_registration which contains the above parameters.
Thus the administrator will have the choice to create a new course based on dotlrn_catalog or dotlrn_registration. Depending of the type further actions or informations will be available to students. Students interested in a course of the type dotlrn_registration need to register during a given period. Depending of the join policy they can either join a course or request membership or have to make a choice.
Installations interested in using the new type have to add the type to the package parameter SupportedTypes.
Other features
---------------------------------------------
The type dotlrn-registration will provide other features like:
Activation of Notification for the various stages during the registration process.
Support for waiting lists
Automatic creation of subgroups once the students where distributed to their groups
Possibility to choose from a list of applets that should be made available to the groups instead of simply installing the default applets defined for classes, communities and subgroups
Example
---------------------------------------------
We have a course called "Introduction to Accounting". This course is offered every semester for undergraduate students. Usually around 800 students attend this lecture. Due to the number of students the lecture is accompanied by up to 8 seminars - all with the same content but usually on different times in order to allow students to be more flexible. Still some seminars are more apealing than others. This could be because of the time, the location, the tutor...Since the sizes of the seminars are rstricted by teh number of seats available students have indicate which seminar the prefer compared to the others. Depending on the configuration set by the course administrator the students have submit a ranking or simply tell which seminar they prefer most and which less. Any number in between is configurable. Once the registration process is over the system recommends a distribution which can be double checked by the course administrator. Finally the distribution is confirmed and 8 subgroups in dotlrn are created and the memberships assigned. If the course administrator wishes all accepted students are notified. He can also notifcy the rejected students or add them to a waiting list.
In order to allow the above scenario it takes the professor 2-3 minutes to define it and further 5 minutes to trigger the distribution. The algorithm to optimize the above problem is takes for a situation of 1000 students and 1000 seats (1 mio elements matrix) around 4 min on a 1-CPU 3.1 Ghz Intel Box.
We have also implemented the distribtion types first-come-first-served as well as random.
The intention of the dotlrn-catalog is to be that, a catalog of courses (past, present, future), and to which areas within the institution those courses belongs to.
For a registration process, I'll suggest to have it outside of dotlrn-catalog, we'll keep the systems more modular, and at the same time, more extensible. You might substitute dotlrn-catalog course to assessment relation, to course to "registration-process" relation, and that registration process can be an external system, like the one you propose or a simple assesment.
What do you think?
The only extension I see so far for dotlrn-catalog, in order to make it more usable for dotlrn real scenarios, is to add roles to the areas (faculty of medicine for example), and propagate permissions to those roles (users) in the class instances.
You might substitute dotlrn-catalog course to assessment relation, to course to "registration-process" relation
So far assessment is only an attribute of the type dotlrn_catalog:
content::type::attribute::new \
-content_type "dotlrn_catalog" \
-attribute_name "assessment_id" \
-datatype "integer" \
-pretty_name "\#dotlrn-catalog.asm_id_pretty_name\#" \
-sort_order 4 \
-column_spec "integer"
Who would you realize the definition of relations technically? Does the CR API provide anything for this purpose?
Greetings,
Nima
do you have a demo site? I assume curriculum central does not work together with dotlrn catalog, right? What can a student on course level? Can he join?
Greetings,
Nima
you have 3 choices, to relate objects to one another.
For strictly CR items you can use cr_item_rels.
For cr_items to other objects use acs_rels or the related_items package.
Of course, an old-fashioned mapping table is always an option.
