General plugins

Introduction

I've been lurking around these forums for the last couple weeks or so learning more about moodle and looking for a project I might be able to contribute to. One of the things I've noticed discussed from time to time was the idea of a subsection and I decided this would be very useful in my own course. 

Definition and rationale

By subsection, I mean a new activity module that did not provide any content itself, but rather served as a container object for other activity modules. This would allow arranging content into a hierarchical structure. I do have reservations: one feature I like in moodle is that everything is one page so there's no digging to find. But Ive found that my sections' length has quickly grown unwieldy. Additionally, I think the ability to arrange information in a hierarchy can be inherently useful in teaching by helping to convey a framework for mental organization. Ultimately, it gives more flexibility to the teacher.

Goals

1) Minimal modification to existing moodle code and data structures--make the subsection as self-contained as possible.
2) Leverage existing code to handle display and maintenance of modules.
3) Allow arbitrary creation of subsections and unlimited nesting.

Methodology

The technique used is basically Sean Keogh's trick for pseudo-subsections expanded into a full-blown module. See this discussion and this one. A table is created to store subsection information that includes a link to a newly added row in the course_sections table. These additional sections are "hidden" since they exceed the number of sections defined in the course--but can be viewed through the subsection module. Limitations

I see this activity as a short-term kludge to the problem of subsections. It is inelegant, but I think a more elegant solution may require tighter moodle core code integration. Major issues include:

1) The creation or maintenance of subsections returns you to the main screen rather than the subsection so editing is cumbersome.
2) Deleting a subsection may leave modules "orphaned" (should they just be deleted when the containing subsection is or should there be an interface for "adopting" em?)
3) Pull down navigation menu does not properly label subsections.
4) Some changes were required to course/lib.php.

Changes to course/lib.php

I wanted to keep the left hand column in my subsection view, but its designed to be on a page that exists in the course directory. Changes to lib.php mostly involved replacing relative directory paths with $CFG->wwwroot/course.

Future

In the immediate future, Id like to try to overcome some of the limitations listed above and am looking for suggestions as to how to best do this. In the longer term, working on this subsection project has gotten me thinking about underlying data organization questions. It seems that ideally sections and subsections would be the same beast. A subsection would just be a section with a parent. Sections could be added and deleted from courses just like other modules, instead of by adjusting a course propertysection numbers.

Database proposal: I wonder if it would make sense to create a separate table that correlated sections, modules, and courses in moodle? The current schema stores a modules section with the module record and the contained modules in the section record. But a section is not really an intrinsic characteristic of the module, is it? Wouldn't a separate relational table provide more flexibility in terms of module organization (many-to-many relationships would be possible allowing a module to be listed in multiple sections) and better database normalization (no redundant information spanning tables)?

Perhaps subsections could be implemented together with a complementary new course format? Right now it seems that the course formats are pretty tightly integrated with the core moodle code. The database change above would give course formats more flexibility in how to organize the course. This could help move towards a more modularized course format structure. One possibility, for example, might be that every course format has a function call executed when a new course of that type is created (analogous to a modules add_instance) function. This function call would then create the sections necessary for a particular courses organization. For example, the weekly format would create a section for each week in the course in this function.  End user behavior would be the same, but the underlying code structure would be more flexible.  Course formats could create their own supporting database structures, but would need to provide certain common data functions to properly interface with modulesperhaps through methods similar to how modules now work.  They could query user options through interfaces.  The real power of modules is that they are free to do whatever they want provided they implement certain well-defined functions, and provide certain well-defined data members. Wouldnt it be neat if course formats worked similarly?

Wrap-up

Im pretty new to moodling and I very much appreciate any and all feedback. This is truly an amazing project. Ive been using Moodle in a class I teach and Ive thoroughly enjoyed working with it. Better yet is the positive feedback Ive gotten from students. Thanks to Martin and the community for this terrific system,

--Rudy