Action Learning Environment (ALE)

ALE is for building active learning communities. That word, interactive, implies that ALE has a bigger objective than helping technophobic faculty put course notes up on the web. Its real goal is to exceed the interactivity that is possible in a face to face classroom, subject only to the bandwidth limitations of the web.

Each ALE course is defined by a remarkably small number of files, mostly written in XML. The name, size (in bytes), and function of each is shown in this table and explained at more below in terms of an anatomical example. Detailed descriptions are available via the links in in the orange bar at the top of this page.

Notice that the number of files is small: one file defines each task, four (course.xml, outerPages.xml, portalPages.xml, and innerPages.xml) defines the course, and one defines the look and feel. The remaining two (jdbc.properties and ale.jar) can be regarded by instructors as hard-coded stuff that you don't have to understand to get a course on the air.

Courses are the bones

Each course is defined by a course.xml file in the top level (root) directory for that course. It defines the skeletal framework upon which everything else will be hung. The location of all other course components are specified here, but all components are typically in subdirectories of the course directory. This file also defines the lesson plan as a sequence of lesson elements, each which may assign any number of task elements. The tasks are each defined by separate task files as described below.

Tasks are the meat

Each task is defined by an XML file that defines the name and title of an element of work and the page elements that make up the task. Page elements are simply XHTML code, extended with several additional custom XHTML commands for inserting quizzes within the XHTML code. Unlike conventional XHTML, pages may also contain executable code, written in the Velocity HTML extension language, which is the means for supporting the interactive features that makes ALE unique.

Pages are the skin

Pages are just like Tasks but are available without going through the login process. Pages are not scheduled and the automated interactive machinery that supports tasks aren't available to them. This doesn't mean cannot be interactive, but that their interactivity must be hand-coded. The pages you're reading now are pages, not tasks, since they can be accessed without logging it. Pages are used for external material such as home pages, registration procedures, login/logout procedures, and so forth. The student locker and instructor tools for reviewing task materials are defined as pages too.

There is no need to separate pages into separate files. But the ALE tutorial divides its pages into three files in a separate directory, called pages, to show how it's done. pages/outerPages.xml defines externally accessable pages, pages/portalPages.xml define the login, registration, and logout procedures, and pages/innerPages.xml define the student locker and faculty task review procedures, plus several routine procedures that the ALE system requires as described below.

The ALE system needs to know where a few special pages are located and will raise a fault if pages with these identifiers are not defined somewhere.

locker: The page that displays the student locker
home: The home page for the course
notfound: A page to be displayed when a requested page is not found
fault: A page to be displayed if a software fault is encountered
refuse: A page to be displayed if the user requests a page they're not allowed to (for example, a student requesting the faculty review page).

LookAndFeel is the personality

Look and Feel issues are all isolated into a single file, velocity.macros. This contains Velocity macros that provide a consistent look and feel to all pages in each course.

Java is the brain

Finally, all of the above rely on the Jetty servlet engine which is written in Java, as is Velocity, and the other infrastructure everything else relies on. The infrastructure parses the XML files to populate Course, Task, Page and Procedure classes whenever the XML files that define them is changed. As browser requests arrive, the servlet engine creates Controller instances to service them, which treats their contents as Velocity programs, sending the resulting HTML code to the browser. The velocity statements within each Page interact with ALE objects (Course, Lesson, Task, Page, Question, Answer, etc) to determine what the student sees in their browser.

Database is the memory

The ALE objects above are all transient, derived from XML files each time the files are changed. They exist only until the servlet engine is restarted. Persistent storage of student answers, instructor responses, and grades are all persist in a database. Since few instructors have database expertise, the database is handled automatically. Currently the database is MySQL, but I'm looking into converting to Berkeley DB to make the installation procedure less intimidating.

More to come

ALE 0.1	© Copyright 2004 by Brad Cox	Mar 2004
Served by JohnCompanies.com

ALE Reference Manual