Template:Infobox nrhp/coding

From Wikipedia, the free encyclopedia

This page contains programming notes about internal coding of the Template:Infobox nrhp. Similar to many other templates, the template is coded in MediaWiki language ("{{#ifeq:...}}"), a beta technology used by many wiki websites. The template defines the infobox table using wikitable language tokens, such as: opening a table with "{|" and putting rows with "|-" and cells with "|" then closing with "|}".

Various issues are explained below.

Contents

[edit] Infobox structure

The Infobox_nrhp template creates an infobox using a wikitable, 2 columns wide, topped by a title bar and subtitle bar, followed by the image/map area, with the 2 bars and area, each spanning the 2 columns by using wikitable directive "colspan=2" along with the text-centering directive (style="text-align: center;"). After the image/map area, the remaining data is displayed in the 2 columns, paired as each "Label:" + value.

[edit] Wikitable layout

The table layout uses the typical wikitable tokens, such as: opening the table with "{|" and putting rows with "|-" and cells with "|" (on separate lines), then closing with "|}".

Title of Landmark-1
Subtitle of Table
Label-1: value-1
Label-2: | value-2
Label-3: value-3
Much longer label-4: value-4


For example, the above wikitable is coded as:

{| class="infobox" style="width: {{{boxwidth|260px}}}; font-size: 90%;"
! colspan=2 style="background-color: #A8EDEF; text-align: center" | Title of Landmark-1
|-
! colspan=2 style="background-color: PaleGreen;" | Subtitle of Table
|-
| style="text-align: left;" | '''Label-1:'''
| value-1
|-
| style="text-align: left;" | Label-2: | value-2 <!--won't work-->
|-
| style="text-align: left;" | Label-3: || value-3
|-
| style="text-align: left;" |'''Much longer label-4:'''||value-4
|}

Issues to consider for the infobox table:

  • Infobox width: Note on the top line, parameter "boxwidth" sets the width of the infobox, which defaults to "260px" wide (when "boxwidth" is omitted from the article).
  • Separating rows/cells: For "Label-2" notice the alignment problem and how the 2nd-column value must be placed with the bar "|" on a separate line, as done with value-1, or else separated by double-bar "||" as with value-3.
  • Hiding vertical-bars: Within an if-statement, the vertical-bar "|" is generated by template "{{!}}", to avoid confusion with the vertical-bars separating the then/else clauses; however, the literal exclamation mark "!" can be coded directly.

The actual NRHP infobox is structured as a similar table, formatted into 2 columns by specifying class="infobox" at the top.

[edit] One-liner coding

Many templates, such as Infobox_nrhp, have been written in the typical one-liner style, with much of the source code written as a long string of nested brace "{{..}}" expressions, rather than as indented source code. The effect of the one-liner coding has been rambling expressions:

{{#if:|then|{{#if:|then}}|else{{#if:|then|else}}}}

However, it is possible to write the template code in a more structured, indented style, to align if-statements and others, such as when checking to display the mayor's name:

{{#ifexist: {{{mayor|}}} <!--when name is an article-->
|<!--then-wikilink-->[[{{{mayor|}}}]]
|<!--else-nolink-->{{
#ifeq:{{{mayor|<noinclude>x</noinclude>}}}|x
|<!--then-say-text-->{{{mayor}}}
|<!--else-show-name-->{{{mayor|}}}
}}<!--endifeq-->
}}<!--endifexist-->

Decades of computer-language design has shown that coding 2 nested if-statements as indented, across 8 lines, is preferable to a compact "one-liner" string that wraps onto only 3 lines of text. Although the source code becomes over twice as long, it is easier for others to read and modify, for inserting more if-statements within the indented structure. Many people writing the one-liner templates, as a wrapped string of source code, know full well how to write structured, indented source code, but there has been a wiki sub-culture of one-liner coding that has dominated the writing of templates. It takes time to re-write and clarify all that condensed one-liner coding.

The coding of template Infobox_nrhp has still contained many one-liner sections, as of October 2007; however, the template code can be re-written to use the more structured, indented-code style, over time.

[edit] Indenting template code

The template code can be indented onto separate lines; however, the double-brace "{{" typically cannot be indented past column 1 on a line, so the "#if" or "#ifeq" must be indented apart from the "{{" double-brace. Leaving the double-brace at the end of the previous line might be the easiest split:

<!--previous line--> {{
#ifexpr: {{{Az}}} < {{{Bz}}}
|<!--then-show--> Yes, Az lower than Bz={{{Bz}}}.
|<!--else-show--> No, Az NOT lower than Bz.
}}<!--endifexpr-->

In the above example, the double-brace "{{" is left on the previous line, separated from the indented "#ifexpr" on the subsequent line. Indenting a double-brace can cause the whole line to be treated as a quote-box, as follows:

 {{#ifexpr: {{{A}}}={{{B}}} <!--this indented line became this box-->

Since an indented double-brace might be treated as a quote-box, the double-brace could be left on the previous line, split from the indented "#ifexpr" line.

[edit] Impossible templates

Okay, yes, working on the wiki templates can be very difficult. Detailed templates, such as the Infobox_nrhp, involve so many details that they rarely get properly tested and restructured for logical sequence, compared to the work needed to develop professional software. In a sense, these templates would not have been available at this time, due to the many man-hours needed for the full complex development, so these are "impossible templates" which wouldn't even exist now, except at this current level of "stub" or "prototyping" software. Please encourage experienced computer programmers to help develop these templates, because the MediaWiki language is only a beta-level technology, and disciplined designers are needed to engineer better templates, patched for that beta-level language.

[edit] MediaWiki language bugs

Along with many design problems in the MediaWiki software used by Wikipedia, are the numerous simple bugs. For example (in Sept. 2007), when displaying an image, the "center|" option would chop the bottom pixel line of the image; similar chopping occurred when trying to resize an image. During Sept. 15-18 (2007), many images used from Wikimedia Commons went blank because the thumbnailer "disk array became full" as if no one saw the disk-space running low. Most of the underlying technology has been in an infantile state for years; of course, software people burn-out trying to fix those problems, and then wiki editors are forced to spend hours working around simple bugs that persist for years. At this stage, plan hours to perform a simple task, and remember that many others are also suffering and frustrated. However, Wikipedia is an interesting study in failed concepts. If they "fail to plan, plan to fail" is true in this situation as well. Be patient, expect more problems, and learn from the mistakes.

Other bugs:

  • Omitted closing </noinclude> - At the bottom of a template, descriptive text is bypassed during template execution by using tag "<noinclude>", and the paired closing end-tag "</noinclude>" must be placed at the bottom of the template, or else all the "non-included" text might become totally included (perhaps intended as an error-indicator action). By common practice, in other software, typically, an unclosed tag would be implicitly closed at file-end, or would simply state "missing end-tag '</noinclude>'"; however, the MediaWiki language does the defiant opposite and just dumps ALL "non-included" text as totally included, for the implicit action, giving the impression that the opening tag "<noinclude>" is invalid or being skipped.

[edit] Debugging of templates

Many, many Wikipedia templates still contain pre-existing bugs that just could not be detected, pinpointed and fixed, due to all the nested braces: "{{ {{{|}}} {{ {{{|{{{}}} }}} }} }}...". Some major issues to consider:

  • Verify the pairing of braces: Extra braces "}}" have been thrown into some templates (of course) just to pair an unclosed if-statement (somewhere else) and get the basic functionality to work.
  • Debug your own copy: A template can be copied, for debugging, into a user's files by prefixing the user-name onto a new article "User:XXX/Template:Infobox_zzz" (and such). The created article can then be re-edited many times without hacking the original. Test within any article by prefixing the original template name with "User:XXX/Template:" (don't forget the word "Template:"), but don't save a tested live article as calling that user-name template, just preview the changes only, or save any new changes while still linking the old template.
  • Test small changes: The safest way to develop a template is to, incrementally, code-a-little, test-a-little; then when something goes wrong, only a few things were changed which most-likely caused the problem. Inspect the few small changes to detect the culprit.
  • Note bizarre results patterns: In general, when something goes wrong in coding MediaWiki language, bizarre performance is activated, and the results can be quite puzzling. However, patterns can be spotted to trace some bizarre results always back to specific causes. In particular, seeing "}}" pop up means: that extra double-braces were encountered, and there were not enough opening double-braces to match the ending double-brace found.
  • Comment/indent code segments: An age-old debugging trick is to added short ending comments to mark the end-braces with related end-ifs: "}}<!--endif a=b-->". Every time an if-statement is added, immediately insert the paired ending "}}" before filling in the inside details of the if-statement; that way, the ending braces are less likely to be forgotten when focusing on the detailed logic.
  • Scan for misspelled parameters: Misspelled parameter names can be detected by loading a template file into a spell-checker and listing all the words used, to hunt for slight variations in spellings.

Those are a few key tips for debugging of templates.