Content deleted Content added
→Style: rm |
rearrange |
||
Line 6:
<syntaxhighlight lang="lua">
place.type = {
shield = "", }
</syntaxhighlight>
Line 16 ⟶ 18:
*<code>name</code> specifies the name of the route displayed by an infobox
*<code>link</code> specifies the target of a link generated, if any
*<code>abbr</code> determines the displayed abbreviation.
====Other types====
*<code>shieldmain</code> is used when a different shield is desired at the top of an infobox, such as for county roads.
<syntaxhighlight lang="lua">
Line 30 ⟶ 32:
}
</syntaxhighlight>
*<code>shieldlist</code> is used when a different shield is desired in lists that utilize the {{tl|Routelist row}} series of templates.
*<code>base</code> can be used for aliasing different types that have a similar base structure, such as U.S. Highway special routes.
*<code>banner</code> stores the name of the
*<code>width</code> stores a code representing the width of the shield. It is most often helpful when used with <code>banner</code>. Can be omitted entirely when unused. Common values are <code>square</code> and <code>expand</code>.
Line 40 ⟶ 44:
<syntaxhighlight lang="lua">
MO.US = {
shield = "US %route%.svg", } MO["US-Alt"] = {
shield = MO.US.shield, }
</syntaxhighlight>
Line 130 ⟶ 87:
The second special string is in the form of <code>[arg|equals|then|else]</code>. This functions as a rudimentary if-then-else statement. The parser tests the value of <code>arg</code> to see if it is equal to the value specified in <code>equals</code>. <code>equals</code> may be empty, in which case the parser tests the existence of the <code>arg</code> argument. If the result of the test is true, the statement is replaced with the value of the <code>then</code> block. Otherwise, it is replaced with the value of the <code>else</code> block.
The two statements may be combined. The parser will parse the if-then-else statement first, and then perform the argument inclusion. This combination is commonly used with bannered routes in the United States, where the <code>dab</code> argument is tested and the link disambiguation is adjusted accordingly, as follows
<syntaxhighlight lang="lua">
AL["US-Bus"] = {
shield = "US %route%.svg", }
</syntaxhighlight>
Line 146 ⟶ 105:
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]]):
<syntaxhighlight lang="lua">
AR.AR = {
shield = { default = "Arkansas %route%.svg", }, } </syntaxhighlight>
Line 158 ⟶ 121:
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]]:
<syntaxhighlight lang="lua">
local regionalShields = {
arg = "county", ["52"] = "Simcoe county road 52.png", }
}
</syntaxhighlight>
Line 172 ⟶ 139:
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]]):
<syntaxhighlight lang="lua">
GBR.B = {
shield = { ifexists = true, ifexists = true,
default = "UK road B%route%.png"
}
},
link = "",
abbr = "B%route%"
}
</syntaxhighlight>
Line 185 ⟶ 158:
Generally speaking, a hook is called by setting the <code>hook</code> field in a table as equal to the name of a hook. Hooks receive two arguments, both tables: <code>parameters</code>, which is the table in the definition; and <code>args</code>, which is simply the table of arguments normally passed to the parser. The hook returns a string, which is then parsed as usual. A powerful feature of hooks is that they can add arbitrary values to the argument table, which may be referenced in the string returned by the hook. Generally, the format string returned by the hook is specified in some form by the <code>default</code> field of the table, though there are exceptions. Here is an example of a hook (from [[Module:Road data/strings/MEX]]):
<syntaxhighlight lang="lua">
MEX.SH = {
shield = { ifexists = true, },
link = {
hook = "mask",
mask = "Road data/masks/MEX",
base = "state",
masked = "fullstate",
default = "%fullstate% State Highway %route%"
},
abbr = "SH %route%"
}
</syntaxhighlight>
Line 203 ⟶ 182:
Functionality exists to display multiple shields for one route, which is used to display tolled and free shields for routes where they differ. This is done by supplying a table with two values, which are listed without indices. The parser is called twice by the calling module, and it returns one shield per call. An example may be found in [[Module:Road data/strings/USA/TX|Texas]]:
<syntaxhighlight lang="lua">
TX.Both = {
shield = {"Texas %route%.svg", "Toll Texas %route% new.svg"}, }
</syntaxhighlight>
Line 224 ⟶ 205:
There are two ways to define a type as an alias. If the type is defined within the module, simply set the new type as equal to the type being aliased, as shown above (from [[Module:Road data/strings/HKG]]):
<syntaxhighlight lang="lua">
HKG.Route = {
shield = "HK Route%route%.svg", } HKG.route = HKG.Route
</syntaxhighlight>
Line 237 ⟶ 220:
This code sets the <code>NY</code> type as a link to the <code>NY</code> type in [[Module:Road data/strings/USA/NY]]. The parser will import that module and process the type as if the original module had declared it itself. The alias declaration may not add or override any data in the type table it points to.
===Inheriting types===
It is possible to predefine several types for a ___location by inheriting them from another module. In this example, the module for Albania inherits all of the specified types from the Europe module.
<syntaxhighlight lang="lua">
-- Albania
local ALB = {}
local util = require("Module:Road data/util")
util.addAll(ALB, require("Module:Road data/strings/EUR"))
</syntaxhighlight>
{{n.b.}} Only one module may be inherited at this time. <!-- if they don't intersect it might not be true -->
==Advanced uses==
It is possible to create multiple types based on a specified pattern using <code>ipairs</code>. In this example from [[Module:Road data/strings/USA/WA]], the <code>US 1926</code>, <code>US 1948</code>, and <code>US 1961</code> types are all created from the same code. At the bottom that is an override for <code>US 1961</code>'s <code>shieldmain</code>.
<syntaxhighlight lang="lua">
for _,year in ipairs({"1926", "1948", "1961"}) do
WA["US " .. year] = {
shield = format("US %%route%% (%s).svg", year),
shieldmain = format("US %%route%% Washington %s.svg", year),
base = WA.US.base,
name = WA.US.name,
link = WA.US.link,
abbr = WA.US.abbr,
width = "square",
}
end
WA["US 1961"].shieldmain = "US %route% (1961).svg"
</syntaxhighlight>
Similarly, subtypes can be created in the same manner. This example creates 9 subtypes each for <code>WA</code> and <code>SR</code>. The <code>aux</code> is inherited from [[Module:Road data/strings/USA]]. That, in turn, modifies <code>auxType</code> and <code>spec</code> accordingly.
<syntaxhighlight lang="lua">
for _,type in ipairs({'WA', 'SR'}) do
for _,auxType in ipairs({"Alt", "Bus", "Byp", "Conn", "Opt", "Scenic", "Spur", "Temp", "Truck"}) do
local spec = WA[" aux "][auxType]
WA[type .. "-" .. auxType] = {
shield = WA[type].shield,
shieldmain = WA[type].shieldmain,
name = WA[type].name .. " " .. spec.name,
link = WA[type].link .. " " .. spec.name .. suffix,
abbr = WA[type].abbr .. " " .. spec.abbrsuffix,
banner = spec.bannerprefix .. " plate.svg",
aux = spec.aux,
width = WA[type].width
}
end
end
</syntaxhighlight>
==Style==
There are a few style guidelines that should be followed:
# Align table fields using
# Each table field should be on its own line.
# Add spaces to either side of an assignment operator (equals sign).
| |||