\label{Authoring_Library_Scripts}
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.\index{library}
\null
\noindent \textbf{Storing entire scripts}
Entire scripts can be stored in a library file. The entire script can then be imported
into a problem file. \index{library}\index{random\_permutation}
\null
\noindent Library file:
\begin{verbatim}
\end{verbatim}
\noindent Problem file:
\begin{verbatim}
randomletter.library
The random letter is $letter.
\end{verbatim}
\null
\noindent \textbf{Storing a portion of a script}
A portion of a script, such as a large data array can be stored in a library file.
\null
\noindent Library file:
\begin{verbatim}
\end{verbatim}
\noindent Problem file: (note the $<$script$>$ tag is repeated and other
script calculations can be done using variables from the library file.)
\begin{verbatim}
randomletter.library
The random letter is $letter.
\end{verbatim}
\null
\noindent \textbf{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)
\begin{verbatim}
/res/msu/raeburn/cleaneq.library
\end{verbatim}
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.
\begin{verbatim}
/res/msu/raeburn/cleaneq.library
Here is an example equation:
Without cleaneq: $eq
With cleaneq: $eq2
\end{verbatim}
\null
\noindent \textbf{Assigning random problems using libraries}
Libraries can be used to store alternative parts of problems which are
selected with the $<$randomlist$>$ tag.\index{randomlist}\index{randomizing parts}
The .library file
hold the all content that would normally appear inside the $<$part$>$ tag.
\begin{verbatim}
sample1.library
sample2.library
sample3.library
sample4.library
sample5.library
sample6.library
\end{verbatim}
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 \ref{Authoring_Scripting_Tags}.
\null
\noindent \textbf{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.
\null
\noindent \textbf{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.\index{script variables, viewing}
\null
\noindent \textbf{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.)\index{*response} are defined in a
.library file, this results in an extra id item in the identifier
required in \&EXT() \index{\&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 *response items have ids of 11 and 12 respectively, the
most recent submissions could be retrieved with the following \&EXT() calls.\index{\&EXT}
\texttt{\&EXT(\char`\"{}user.resource.resource.a.15\_11.submission\char`\"{});}
\texttt{\&EXT(\char`\"{}user.resource.resource.b.15\_12.submission\char`\"{});}