Skip to content

Question blocks

Introduction

Question blocks add flexibility to STACK questions by adding functional structures to the CASText. These are new from v4.0 onwards.

For example, you can add in a conditional statement to selectively include materials in the version of the CASText depending on values of variables. This is useful in randomly generated contexts, especially within model solutions and randomly generated diagrams/charts.

For maximum flexibility, blocks can be nested and conditionally evaluated. A body of CASText is then repeatedly processed until all blocks have been interpreted into CASText. This is a core part of CASText and so applied to all appropriate parts of the question.

Note: The parameters to blocks in the question body may NOT depend on the student's answers. This means that you cannot reveal an input block based on student input, well not just by using an [[if/]]-block. But you may still adapt PRT feedback as much as you want. Such adaptation requires persistent modifiable question state and is not currently possible in STACK; however, there is work being done to create systems that would allow it.

Block groups

Question blocks are divided into three broad groups.

  1. Static blocks, which are active when a question version is created.
  2. Lang
  3. Comment
  4. Debug
  5. Textdownload
  6. Include
  7. Template
  8. Hints/fact sheets
  9. Conditional blocks, for looping and branching and programatic structures.
  10. Define
  11. If
  12. Foreach
  13. Dynamic blocks, which manage features like Javascript and JSXGraph components.
  14. Reveal
  15. JSXGraph
  16. JSString
  17. Parsons
  18. System blocks, which are not realy intended for end-users.

General syntax

The syntax is quite similar to XML but preserving the style [[ ... ]] used in the inputs and potential response tree declarations.

[[ block_type param1="value1" param2='value2' ... paramN="valueN" ]]
Some content.
[[/ block_type ]]

This syntax avoids issues with the rich text editors used in Moodle but it is still recommended to use the plain text editor to avoid excess line changes and white space generated by the WYSIWYG editors.

Notes

  1. In closing a block you must use [[/ "blockname"]] where "blockname" must be used, and it must match the previous opening block.
  2. White space is tolerated in block definitions and after the / in the closing block, but is not necessary.
  3. The parameters have the following syntax: param1="value1". Blocks define what are valid identifiers and parameters. The identifiers must not be in quotes (and so cannot contain spaces). The parameters must be in quotes, and either param1="value1" or param1='value1' is accepted.
  4. Typically param1 will be a valid Maxima identifier, e.g. a variable name and the value would be a valid Maxima expression.
  5. The parameter value must be surrounded by quotes, and both "value" and 'value' are accepted.

Empty blocks

Some blocks do not have content. For example, the [[ define x='1' /]] block does not include content. The following is correct syntax:

[[ define x='1']][[/ define]]

But we think the following is much more direct, and clean.

[[ define x='1' /]]

There are other kinds of [[ emptyblocks /]], which are useful in certain cases and developers of new blocks might like to consider this as a possibility.

While the define block does not generate any visible content, empty blocks may be used to generate output. For example [[ debug /]] does generate output.