A LON-CAPA .library file can contain just a script block, or just response items, or both. A LON-CAPA problem can import as many published library files as desired. A .library file always starts with a < library > tag, and always ends with a < /library > tag.
Storing entire scripts
Entire scripts can be stored in a library file. The entire script can then be imported into a problem file.
<library> <script type="loncapa/perl"> @alpha=('A','B','C','D',); $seed=&random(1,1000000,1); @alpha=&random_permutation($seed,@alpha); #scramble order $letter = $alpha; #select first element </script> </library>
<problem> <import id="15">randomletter.library</import> <startouttext />The random letter is $letter.<endouttext /> <!-- other problem tags could go here --> </problem>
Storing a portion of a script
A portion of a script, such as a large data array can be stored in a library file.
<library> <script type="loncapa/perl"> @alpha=('A','B','C','D',); $seed=&random(1,1000000,1); @alpha=&random_permutation($seed,@alpha); #scramble order </script> </library>
Problem file: (note the < script > tag is repeated and other script calculations can be done using variables from the library file.)
<problem> <import id="15">randomletter.library</import> <script type="loncapa/perl"> $letter = $alpha; </script> <startouttext />The random letter is $letter.<endouttext /> <!-- other problem tags could go here. --> </problem>
Storing a subroutine
Another use of a .library file is to define a subroutine which you plan to call in a number of instances, e.g., (see notes below about browsing libraries in the repository to see the contents of this subroutine)
Here is some example XML problem code which makes a call to the &cleaneq() routine defined in the library file, passing some arguments: $eq,'x','y','z' in the call to the routine.
<problem> <import id="15">/res/msu/raeburn/cleaneq.library</import> <script type="loncapa/perl"> $eq = "1x + 0y +-7z --3"; $eq2 = &cleaneq($eq,'x','y','z');</script> <startouttext />Here is an example equation:<br /> Without cleaneq: $eq<br /> With cleaneq: $eq2<endouttext /> </problem>
Assigning random problems using libraries Libraries can be used to store alternative parts of problems which are selected with the < randomlist > tag. The .library file hold the all content that would normally appear inside the < part > tag.
<part id="11"> <randomlist show="1"> <import id="12">sample1.library< /import> <import id="13">sample2.library< /import> <import id="14">sample3.library< /import> < /randomlist> < /part> <part id="15"> <randomlist show="1"> <import id="16">sample4.library< /import> <import id="17">sample5.library< /import> <import id="18">sample6.library< /import> < /randomlist> < /part>
Note: when using < randomlist > as shown above, all students will work every part of the problem, but the actual problem statements will be different. Another option is to wrap multiple < part > tags but then not all students will work all parts unless the value of `show' equals the total parts wrapped. For more information see section .
Viewing the text contents of a library script block
If you click on a .library file when browsing the shared content repository, and the .library file contains just a script block, then nothing will be displayed in the pop-up window.
The code is viewable if the author has enabled access to the source XML when publishing a .library item that is pure script block. If that is done, then when a user checks the "Source Available" checkbox when browsing the shared content pool, a link will be displayed for items with available source code. Clicking the "Source Code" link for any such items will open a pop-up which displays the content of the library file. It is good practice to enable access to the source code when publishing any library that will be shared. Otherwise, users cannot see it.
Viewing variables from a library script during testing
When viewing a problem in the problem testing mode of Authoring Space, you will see a separate Script Vars link at the bottom of the testing area for each script block (either a block included directly within the file, or a block included within a library file imported into a problem). By clicking the respective link, you can view variable values from the respective script.
Accessing submissions from a problem part loaded from a library
When *response items (e.g., *response is a wildcard such as optionresponce, stringresponse, numericalresponse, etc.) are defined in a .library file, this results in an extra id item in the identifier required in &EXT() functions, e.g., if a problem contains two parts with ids of a and b respectively, and the id of the < import > for the .library is 15, and the *reponse items have ids of 11 and 12 respectively, the most recent submissions could be retrieved with the following &EXT() calls.