Skip to main content
\( \newcommand{\lt}{<} \newcommand{\gt}{>} \newcommand{\amp}{&} \)

Section9.2WeBWorK Problems in Source

A <webwork> tag must be inside an <exercise>, optionally preceded by an <introduction>, and optionally followed by a <conclusion>.

<exercise>
    <introduction>
    </introduction>

    <webwork>
    </webwork>

     <conclusion>
     </conclusion>
</exercise>

There are several methods for putting content into the <webwork>. (Note that an empty <webwork> with no attributes will simply produce the camelcase WeBWorK logo.)

Subsection9.2.1Using an Existing WeBWorK Problem

If a problem already exists and is accessible from the anonymous course's templates/ folder, then you can simply include it as a @source attribute. For example, if it is a problem in the Open Problem Library (OPL) then relative to the templates/ folder, its path is Library/... and you may use:

<webwork source="Library/PCC/BasicAlgebra/Exponents/exponentsMultiplication0.pg" />

Or if you have a problem's PG file, you can upload it into the anonymous course's templates/local/ folder and use it with:

<webwork source="local/my_prolbem.pg" />

Subsection9.2.2Perl-free Problems

If you'd just like to rattle off a quick question with no randomization, you can do as in this example:

<exercise>
    <webwork>
        <statement>
            <p><m>1+2=</m><var name="3" width="5" /></p>
        </statement>
    </webwork>
</exercise>

The above example could be given an optional title, introduction, conclusion, hint, and solution. These are discussed in Subsection 9.2.3.

In the above example, "3" is the @name attribute to a <var> element. This is how to create an answer blank that is expecting \(3\) as the answer. What you give as a @name attribute will be passed as a string to PG's Compute() command, so it needs to be valid input for Compute(). It should not begin with a $.

The default context is Numeric, which understands numerical expressions and formulaic expressions in the variable \(x\text{.}\) You can activate some other context as in this example:

<exercise>
    <webwork>
        <setup>
            <pg-code>
                Context("ImplicitPlane");
            </pg-code>
        </setup>
        <statement>
            <p>The answer is <m>x+y=1</m>.</p>
            <p><var name="x+y=1" width="8" /></p>
        </statement>
    </webwork>
</exercise>

Many special contexts are automatically detected by MBX, and it loads the appropriate macro file into the PG problem. However you may need to explicitly load a macro file as described in Subsection 9.2.3.

You should only use this (nearly) Perl-free shortcut if the @name attribute could be put in math mode and simultaneously serve as a printed answer in something like a solutions manual. In the above two examples, this is the case. But in a question with, say, @name="cos(x)/2", if you'd like the solutions manual to print using \frac{\cos(x)}{2}, then you should write the problem as described in Subsection 9.2.3.

Additionally, in shortcutting around the structure described in Subsection 9.2.3, you will not have access to certain other features, such as answer format help links.

Subsection9.2.3PG code in Problems

To have randomization in problems or otherwise take advantage of the algorithmic programming capabilities of Perl and WeBWorK's PG language requires using a <setup> tag. Having at least a little familiarity with coding problems in WeBWorK is necessary, although for simpler problems you could get away with mimicking the sample article in mathbook/examples/webwork/. A <statement>, (optional) <hint>, and (optional) <solution> follow. The whole thing can have an optional <title>.

<webwork>
    <title>Optional</title>

    <setup>
    </setup>

    <statement>
    </statement>

    <hint>
        <p>Optional</p>
    </hint>

    <solution>
        <p>Optional</p>
    </solution>

</webwork>

The <setup> contains a section of <var> tags followed by a <pg-code>. If you are familiar with code for WeBWorK PG problems, the <pg-code> contains lines of PG code that would appear in the “setup” portion of the problem. Typically, this is the code that follows TEXT(beginproblem()); and precedes the first BEGIN_TEXT or BEGIN_PGML. If your code needs any special WeBWorK macro libraries, you may load them in a <pg-macros> tag prior to <setup>, with each such .pl file's name inside a <macro-file> tag. However many of the most common macro libraries will be loaded automatically based on the content and attributes you use in the rest of your problem.

For each perl variable (scalar, array, or hash) that is used in the <pg-code> and which will also be used in the <statement>, <solution>, or as an answer to an answer blank, there should be a <var>. These <var> tags are primarily to help MBX handle static output, but they also allow for some optimal leveraging of WeBWorK features.

A <var> in the <setup> always has a @name attribute, which should match the variable's name in your <pg-code> (e.g. $x, @a, etc.). Each <var> should usually have a <static> tag with code for the static version of the answer (possibly inside a \text{}). For PDF and other static output modes, this code will be used to print <var> values, since the WeBWorK server will play no role.

Lastly, a <var> in the <setup> can have a @category attribute. This is intended for variables which will be used as answers. Based on a @category, an automatic help syntax link will be provided adjacent to an answer blank. For instance @category="point" will provide a link explaining the syntax for typing a point.

Here is a small example. Following the example, we'll continue discussing <statement> and <solution>.

<webwork>
    <title>Integer Addition</title>

    <setup>
        <var name="$a">
            <static>9</static>
        </var>
        <var name="$b">
            <static>8</static>
        </var>
        <var name="$c" category="integer">
            <static>17</static>
        </var>

        <pg-code>
            $a = Compute(random(1, 9, 1)); 
            $b = Compute(random(1, 9, 1)); 
            $c = $a + $b;
        </pg-code>
    </setup>

    <statement>
        <p>Compute <m><var name="$a" />+<var name="$b" /></m>.</p>
        <instruction>Type your answer without using the <c>+</c> sign.</instruction>
        <p>The sum is <var name="$c" width="2" />.</p>
    </statement>

    <solution>
        <p><m><var name="$a" />+<var name="$b" />=<var name="$c" /></m>.</p>
    </solution>
</webwork>

Within a <statement>, <hint>, or <solution>, reference <var> tags by @name. For HTML and PG output, the Perl variable will be used. For static output, the <var> tag's <static> child will be used.

Within the <statement>, a <var> tag with either a @width or @form attribute creates an input field. The @name attribute declares what the answer will be.

An <var> can have @form="essay", in which case it need not have a @name attribute. This is for open-ended questions that must be graded by a human. The form field will be an expandable input block if the question is served to an authenticated user within WeBWorK. But for the WeBWorK cells in MBX HTML output, there will just be a message explaining that there is no place to enter an answer.

An <var> can have @form="array". You would use this when the answer is a Matrix or Vector MathObject (a WeBWorK classification) to cause the input form to be an array of smaller fields instead of one big field.

An <var> can have @form="popup" or @form="buttons". These are not necessary for HTML and PG output to behave, but are needed if you intend for PDF output to emulate these answer entry field types.

If you are writing a multiple choice question and using @form="popup" or @form="buttons" in your <var>, instead of a <static> in the corresponding <var> from the <setup>, use a <set> tag, with <member> children. The <member> tags would be the multiple choice options, and each can have a @correct="yes" attribute to identify the correct choice(s). There is some unavoidable redundancy between listing these <member> tags in the <setup> and listing them again in the actual <pg-code>.

If you are familiar with PG, then in your <pg-code> you might write a custom evaluator (a combination of a custom answer checker, post filters, pre filters, etc.). If you store this similar to

$my_evaluator = $answer -> cmp(...);

then the <var> can have @evaluator="$my_evaluator".

An <instruction> is specific instructions for how the reader might type or otherwise electronically submit their answer. Contents of an <instruction> will be omitted from print and other static output forms. The <instruction> is a peer to <p>, but may only contain “short text” children.

Subsection9.2.4Reusing a <webwork> by @xml:id

Planned.