Apache::lonnavmap - Subroutines to handle and render the navigation maps
The main handler generates the navigational listing for the course, the other objects export this information in a usable fashion for other modules.
When a user enters a course, LON-CAPA examines the course structure and caches it in what is often referred to as the ``big hash'' . You can see it if you are logged into LON-CAPA, in a course, by going to /adm/test. (You may need to tweak the /home/httpd/lonTabs/htpasswd file to view it.) The content of the hash will be under the heading ``Big Hash''.
Big Hash contains, among other things, how resources are related to each other (next/previous), what resources are maps, which resources are being chosen to not show to the student (for random selection), and a lot of other things that can take a lot of time to compute due to the amount of data that needs to be collected and processed.
Apache::lonnavmaps provides an object model for manipulating this information in a higher-level fashion then directly manipulating the hash. It also provides access to several auxilary functions that aren't necessarily stored in the Big Hash, but are a per- resource sort of value, like whether there is any feedback on a given resource.
Apache::lonnavmaps also abstracts away branching, and someday, conditions, for the times where you don't really care about those things.
Apache::lonnavmaps also provides fairly powerful routines for rendering navmaps, and last but not least, provides the navmaps view for when the user clicks the NAV button.
Note: Apache::lonnavmaps only works for the ``currently logged in user''; if you want things like ``due dates for another student'' lonnavmaps can not directly retrieve information like that. You need the EXT function. This module can still help, because many things, such as the course structure, are constant between users, and Apache::lonnavmaps can help by providing symbs for the EXT call.
The rest of this file will cover the provided rendering routines, which can often be used without fiddling with the navmap object at all, then documents the Apache::lonnavmaps::navmap object, which is the key to accessing the Big Hash information, covers the use of the Iterator (which provides the logic for traversing the somewhat-complicated Big Hash data structure), documents the Apache::lonnavmaps::Resource objects that are returned by
The navmap renderer package provides a sophisticated rendering of the standard navigation maps interface into HTML. The provided nav map handler is actually just a glorified call to this.
Because of the large number of parameters this function accepts, instead of passing it arguments as is normal, pass it in an anonymous hash with the desired options.
The package provides a function called 'render', called as Apache::lonnavmaps::render({}).
The renderer will build an HTML table for the navmap and return it. The table is consists of several columns, and a row for each resource (or possibly each part). You tell the renderer how many columns to create and what to place in each column, optionally using one or more of the prepared columns, and the renderer will assemble the table.
Any additional generally useful column types should be placed in the renderer code here, so anybody can use it anywhere else. Any code specific to the current application (such as the addition of <input> elements in a column) should be placed in the code of the thing using the renderer.
At the core of the renderer is the array reference COLS (see Example section below for how to pass this correctly). The COLS array will consist of entries of one of two types of things: Either an integer representing one of the pre-packaged column types, or a sub reference that takes a resource reference, a part number, and a reference to the argument hash passed to the renderer, and returns a string that will be inserted into the HTML representation as it.
All other parameters are ways of either changing how the columns are printing, or which rows are shown.
The pre-packaged column names are refered to by constants in the Apache::lonnavmaps namespace. The following currently exist:
If you add any others please be sure to document them here.
An example of a column renderer that will show the ID number of a resource, along with the part name if any:
sub { my ($resource, $part, $params) = @_; if ($part) { return '<td>' . $resource->{ID} . ' ' . $part . '</td>'; } return '<td>' . $resource->{ID} . '</td>'; }
Note these functions are responsible for the TD tags, which allow them to override vertical and horizontal alignment, etc.
Minimally, you should be able to get away with just using 'cols' (to specify the columns shown), 'url' (necessary for the folders to link to the current screen correctly), and possibly 'queryString' if your app calls for it. In that case, maintaining the state of the folders will be done automatically.
In addition to the parameters you can pass to the renderer, which will be passed through unchange to the column renderers, the renderer will generate the following information which your renderer may find useful:
The navmap object's job is to provide access to the resources in the course as Apache::lonnavmaps::resource objects, and to query and manage the relationship between those resource objects.
Generally, you'll use the navmap object in one of three basic ways. In order of increasing complexity and power:
$navmap->getByX
, where X is Id, Symb, Url or MapPc. This provides
various ways to obtain resource objects, based on various identifiers.
Use this when you want to request information about one object or
a handful of resources you already know the identities of, from some
other source. For more about Ids, Symbs, and MapPcs, see the
Resource documentation. Note that Url should be a last resort,
not your first choice; it only works when there is only one
instance of the resource in the course, which only applies to
maps, and even that may change in the future.my @resources = $navmap->retrieveResources(args)
. This
retrieves resources matching some criterion and returns them
in a flat array, with no structure information. Use this when
you are manipulating a series of resources, based on what map
the are in, but do not care about branching, or exactly how
the maps and resources are related. This is the most common case.$it = $navmap->getIterator(args)
. This allows you traverse
the course's navmap in various ways without writing the traversal
code yourself. See iterator documentation below. Use this when
you need to know absolutely everything about the course, including
branches and the precise relationship between maps and resources.
To create a navmap object, use the following function:
Once you have the $navmap object, call ->init()
on it when you are ready
to use it. This allows you to check if the course map is defined (see
courseMapDefined below) before engaging in potentially expensive
initialization routines for the genCourseAndUserOptions and
genMailDiscussStatus option.
When you are done with the $navmap object, you must call $navmap->untieHashes(), or you'll prevent the current user from using that course until the web server is restarted. (!)
Thus, this is suitable for cases where you don't want the structure, just a list of all resources. It is also suitable for finding out how many resources match a given description; for this use, if all you want to know is if any resources match the description, the bailout parameter will allow you to avoid potentially expensive enumeration of all matching resources.
scalar(retrieveResources($map, $filterFunc, $recursive, 1)) > 0
which will tell whether the map has resources matching the description in the filter function.
An iterator encapsulates the logic required to traverse a data structure. navmap uses an iterator to traverse the course map according to the criteria you wish to use.
To obtain an iterator, call the getIterator() function of a navmap object. (Do not instantiate Apache::lonnavmaps::iterator directly.) This will return a reference to the iterator:
my $resourceIterator = $navmap->getIterator();
To get the next thing from the iterator, call next:
my $nextThing = $resourceIterator->next()
getIterator behaves as follows:
firstResource()
for the corresponding nav map. finishResource
corresponds to where you want the iterator to end, defaulting to
navmap->finishResource(). filterHash is a hash used as a set
containing strings representing the resource IDs, defaulting to
empty. Condition is a 1 or 0 that sets what to do with the filter
hash: If a 0, then only resources that exist IN the filterHash will be
recursed on. If it is a 1, only resources NOT in the filterHash will
be recursed on. Defaults to 0. forceTop is a boolean value. If it is
false (default), the iterator will only return the first level of map
that is not just a single, 'redirecting' map. If true, the iterator
will return all information, starting with the top-level map,
regardless of content. returnTopMap, if true (default false), will
cause the iterator to return the top-level map object (resource 0.0)
before anything else.
Thus, by default, only top-level resources will be shown. Change the condition to a 1 without changing the hash, and all resources will be shown. Changing the condition to 1 and including some values in the hash will allow you to selectively suppress parts of the navmap, while leaving it on 0 and adding things to the hash will allow you to selectively add parts of the nav map. See the handler code for examples.
The iterator will return either a reference to a resource object, or a token representing something in the map, such as the beginning of a new branch. The possible tokens are:
The tokens are retreivable via methods on the iterator object, i.e., $iterator->END_MAP.
Maps can contain empty resources. The iterator will automatically skip over such resources, but will still treat the structure correctly. Thus, a complicated map with several branches, but consisting entirely of empty resources except for one beginning or ending resource, will cause a lot of BRANCH_STARTs and BRANCH_ENDs, but only one resource will be returned.
The other method available on the iterator is getStack, which returns an array populated with the current 'stack' of maps, as references to the resource objects. Example: This is useful when making the navigation map, as we need to check whether we are under a page map to see if we need to link directly to the resource, or to the page. The first elements in the array will correspond to the top of the stack (most inclusive map).
A resource object encapsulates a resource in a resource map, allowing easy manipulation of the resource, querying the properties of the resource (including user properties), and represents a reference that can be used as the canonical representation of the resource by lonnavmap clients like renderers.
A resource only makes sense in the context of a navmap, as some of the data is stored in the navmap object.
You will probably never need to instantiate this object directly. Use Apache::lonnavmaps::navmap, and use the ``start'' method to obtain the starting resource.
Resource objects respect the parameter_hiddenparts, which suppresses various parts according to the wishes of the map author. As of this writing, there is no way to override this parameter, and suppressed parts will never be returned, nor will their response types or ids be stored.
A Resource is the most granular type of object in LON-CAPA that can be included in a course. It can either be a particular resource, like an HTML page, external resource, problem, etc., or it can be a container sequence, such as a ``page'' or a ``map''.
To see a sequence from the user's point of view, please see the Creating a Course: Maps and Sequences chapter of the Author's Manual.
A Resource Object, once obtained from a navmap object via a getBy* method of the navmap, or from an iterator, allows you to query information about that resource.
Generally, you do not ever want to create a resource object yourself, so creation has been left undocumented. Always retrieve resources from navmap objects.
Every resource is identified by a Resource ID in the big hash that is unique to that resource for a given course. The Resource ID has the form #.#, where the first number is the same for every resource in a map, and the second is unique. For instance, for a course laid out like this:
* Problem 1 * Map * Resource 2 * Resource 3
Problem 1
and Map
will share a first number, and Resource 2
Resource 3
will share a first number. The second number may end up
re-used between the two groups.
The resource ID is only used in the big hash, but can be used in the context of a course to identify a resource easily. (For instance, the printing system uses it to record which resources from a sequence you wish to print.)
All resources also have symbs, which uniquely identify a resource in a course. Many internal LON-CAPA functions expect a symb. A symb carries along with it the URL of the resource, and the map it appears in. Symbs are much larger then resource IDs.
Once you have a resource object, here's what you can do with it:
Every resource has certain attributes that can be retrieved and used:
$res-
{ID}).title()
if the
resource has a title, and is otherwise the last part of the URL (e.g.,
``problem.problem'').
Map Methods
These methods are useful for getting information about the map properties of the resource, if the resource is a map (is_map).
In order to use the resource parameters correctly, the nav map must have been instantiated with genCourseAndUserOptions set to true, so the courseopt and useropt is read correctly. Then, you can call these functions to get the relevant parameters for the resource. Each function defaults to part ``0'', but can be directed to another part by passing the part as the parameter.
These methods are responsible for getting the parameter correct, not merely reflecting the contents of the GDBM hashes. As we move towards dates relative to other dates, these methods should be updated to reflect that. (Then, anybody using these methods will not have to update their code.)
Misc. functions for the resource.
for (split(/\,/, $res->getFeedback())) { my $link = &Apache::lonnet::escape($_); ...
and use the link as appropriate.
Problem resources have status information, reflecting their various dates and completion statuses.
There are two aspects to the status: the date-related information and the completion information.
Idiomatic usage of these two methods would probably look something like
foreach ($resource->parts()) { my $dateStatus = $resource->getDateStatus($_); my $completionStatus = $resource->getCompletionStatus($_);
or
my $status = $resource->status($_);
... use it here ... }
Which you use depends on exactly what you are looking for. The
status()
function has been optimized for the nav maps display and may
not precisely match what you need elsewhere.
The symbolic constants shown below can be accessed through the
resource object: $res-
OPEN>.
Date Codes
Completion Codes
Composite Status
Along with directly returning the date or completion status, the resource object includes a convenience function status() that will combine the two status tidbits into one composite status that can represent the status of the resource as a whole. This method represents the concept of the thing we want to display to the user on the nav maps screen, which is a combination of completion and open status. The precise logic is documented in the comments of the status method. The following results may be returned, all available as methods on the resource object ($res->NETWORK_FAILURE): In addition to the return values that match the date or completion status, this function can return ``ANSWER_SUBMITTED'' if that problemstatus parameter value is set to No, suppressing the incorrect/correct feedback.
Completable
The completable method represents the concept of whether the student can currently do the problem. If the student can do the problem, which means that it is open, there are tries left, and if the problem is manually graded or the grade is suppressed via problemstatus, the student has not tried it yet, then the method returns 1. Otherwise, it returns 0, to indicate that either the student has tried it and there is no feedback, or that for some reason it is no longer completable (not open yet, successfully completed, out of tries, etc.). As an example, this is used as the filter for the ``Uncompleted Homework'' option for the nav maps.
If this does not quite meet your needs, do not fiddle with it (unless you are fixing it to better match the student's conception of ``completable'' because it's broken somehow)... make a new method.