  | 1 of 10
 |   |
| | 1 of 10
| |
The CoWeM macro processor provides support for conditional text, allowing a single source document to serve for both abbreviated slides and a lengthier full-text version.
The markers {{{ and }}} can be used to surround text that will only appear in any output format except Slides.
{{{
This paragraph will appear in
* scrolls
* pages
* but not in slides.
}}}
(Look here to see the slides.)
For the purpose of this example, I am typing {({ and })} instead of {{{ and }}} so that the CoWeM processing does not make conditional markers disappear.
There are a few limitations on the placements of these markers.
* If only a single paragraph is affected, the markers can be placed at
the beginning and end of that paragraph.
{({E.g., like this.})}
* If more than one paragraph is affected, the markers must go in
separate paragraphs.
{({
* Like this.
* Notice that the paragraph form "respects" the indentation
of the regular Markdown text.
* In fact, the closing marker can never appear at a different
indentation than the opening one.
})}
If only a single paragraph is affected, the markers can be placed at the beginning and end of that paragraph.
If more than one paragraph is affected, the markers must go in separate paragraphs.
Conversely, the markers [[[ and ]]] can be used to surround text that will appear only in Slides.
[[[
This paragraph will appear in
* slides
* but not in scrolls and pages
]]]
This paragraph will appear in
(Look here to see the slides.)
The placement rules for these markers are the same as for the preceding everywhere-except-slides markers.
The macro commands that allow this are
Example 1: Selecting TextI might include the following in a course syllabus:
%define
[summerSemester] [] [1]⋮
%ifsummerSemester
The final exam is held on the last day of classes.%else
The final exam is held during exam week, according to thescheduled published by the Registrar's office.%endif
By removing or restoring the %define line, I can quickly switch between summer and regular-semester versions of the yllabus.
Example 2: Suppressing TextSometimes I have old text that I don’t actually want to delete, but don’t want to appear in the current website. I can “comment out” such text like this ….
%if
_ignore⋮
…text that won’t appear in the website…⋮
%endif
Of course, I never define a macro names “
_ignore”.
There are two macros that are pre-defined when processing primary documents:
The format (scroll, slides, pages, directory, …) in which the document is being processed is added as a macro named with a leading underscore, e.g., 1.
In fact, the {{{ and }}} markers introduced earlier are just macros providing a convenient shorthand for %ifnot 1 and %endif.
In the course configuration build.gradle, you can specify a property “delivery”, e.g.,
course {
courseName = 'CS 361'
courseTitle = 'Advanced Data Structures and Algorithms'
⋮
delivery = 'online'
}
Whatever value is given to this property is declared as a macro, again named with a leading underscore. In this example, a macro named _online would be declared.
This property could be any string, but I usually use either “online” or “live”.
I teach many courses in both live and web versions.
In a typical live course, I prepare slides which contain a lot of terse bulleted lists, in which I fill in the details while speaking during the lectures. For example:
When preparing a web version of the course, I revisit those lists, and insert an approximation of what I would have said during lectures, but make this additional text conditional on not being processed in 1_ format.
For example, the original slide
# Integration Testing
\firstterm{Integration testing} is testing that combines
several modules, but still falls short of exercising the entire program
all at once.
* Integration testing usually combines a small number of
modules that call upon one another.
* Integration testing can be conducted
* \firstterm{bottom-up}
* relieves the need for stubs
* or \firstterm{top-down}
might become
Again, for the purpose of this example, I am typing {({ and })} instead of {{{ and }}} so that the CoWeM processing does not make conditional markers disappear.
# Integration Testing
\firstterm{Integration testing} is testing that combines
several modules, but still falls short of exercising the entire program
all at once.
* Integration testing usually combines a small number of
modules that call upon one another.
* Integration testing can be conducted
* \firstterm{bottom-up }
{({
(start by unit-testing the modules that don't call anything
else, then add the modules that call those starting modules
and thest the combination, then add the modules that call
those, and so on until you are ready to test
<span class="function">main()</span>.)
})}
* relieves the need for stubs
* or \firstterm{top-down}
{({
(start by unit-testing <span class="function">main()</span> with stubs for
everything it calls, then replace those stubs by the real
code, but leaving in stubs for anything called from the
replacement code, then replacng those stubs, and so on, until
you have assembled and tested the entire program).
})}
{({It's worth noting that unit testing and integration testing can
sometimes use some of the same test inputs (and maybe the same
expected outputs), because we are testing the software in different
configurations.})}
The upshot of this is that my original slides remain and can still be used for live presentations. But the scroll format will contain the more detailed text, and can be deployed as the web course content or as lecture notes for students in the live version.
| | 1 of 10
| |