Module:Road data/strings/doc: Difference between revisions

Content deleted Content added
Continuing
Continuing
Line 74:
 
When parsing the <code>link</code> field, the parser first checks to see if the <code>dab</code> argument was provided. If so, it replaces the statement with <code>%dab%, </code>. If not, the statement is replaced with the empty string placed in the <code>else</code> block. Then, the parser replaces <code>%route%</code> with the route number and, if the <code>dab</code> argument was provided, <code>%dab%</code> with the value of that argument.
 
===Switching===
Some logic is too complicated to represent with only format strings. This framework provides several methods to express complex data. All of these involve storing a nested table as the value of a field.
 
The most straightforward functionality provided by nested tables is switching. In its most basic form, the table consists of a series of key-value pairs, with the keys being route numbers and the values being the format strings used by those routes. Usually, the format string returned does not need parsing, but the option is there. A <code>default</code> entry should be provided to handle any route numbers not explicitly stated. The following is a representative example of route-based switching (from [[Module:Road data/strings/USA/AR]]):
<source lang="lua">
AR.AR = {shield = {default = "Arkansas %route%.svg",
["917"] = "Arkansas 917-1.svg",
["980"] = "Arkansas 980(Airport).svg"},
link = "Arkansas Highway %route% [dab||(%dab%)|]",
abbr = "Hwy.&nbsp;%route%",
width = "expand"}
</source>
 
In this example, Highways 917 and 980 have non-standard shield names, which are explicitly provided. Other route numbers use the default format.
 
Switching on other arguments is also allowed. The name of the argument to be used for switching is stated in the <code>arg</code> field of the table. Nesting switches on different arguments is also allowed. A good example that uses both forms of switching can be found in [[Module:Road data/strings/CAN/ON|Ontario]]:
<source lang="lua">
local regionalShields = {arg = "county",
["Essex"] = "Essex County Road %route%.png",
["York"] = "York Regional Road %route%.svg",
["Durham"] = "Durham Regional Road %route%.svg",
["Niagara"] = "Niagara Regional Road %route%.svg",
["Simcoe"] = {["52"] = "Simcoe county road 52.png",
default = "Simcoe County Road %route%.JPG"}}
</source>
 
In this example, which is a shield table that is reused by several types in Ontario, the <code>county</code> argument is used for the primary switch. If the route is in Simcoe County, a second switch is performed, this time on the route number.
 
===Existence testing===
Another use for tables is existence testing. If a table has the <code>ifexists</code> field set to <code>true</code>, the parser will perform existence testing on the result of parsing the <code>default</code> field. If the test fails, the result of parsing the <code>otherwise</code> field is returned. Existence testing may be chained by using a second ifexists table as the value of the first table's <code>otherwise</code> field, and so on. Here's an example of nested existence testing (from [[Module:Road data/strings/GBR]]):
<source lang="lua">
GBR.B = {shield = {ifexists = true,
default = "UK road B%route%.svg",
otherwise = {ifexists = true,
default = "UK road B%route%.png"}},
link = "",
abbr = "B%route%"}
</source>