User:Magill/Project-Documentation-Template-doc

From Lotro-Wiki.com
Jump to navigation Jump to search


Documenting Templates in general

Template Documentation


MediaWiki talk:Lord of the tooltips.js
User talk:Eleazaros/coords.js - Test page for new Map pages for Tooltip Coords
Template:Tooltip Coords/doc

Note on updating Javascript

Note: After saving, you may have to bypass your browser's cache to see the changes.
  • Firefox / Safari: Hold Shift while clicking Reload, or press either Ctrl-F5 or Ctrl-R (⌘-R on a Mac)
  • Google Chrome: Press Ctrl-Shift-R (⌘-Shift-R on a Mac)
  • Internet Explorer: Hold Ctrl while clicking Refresh, or press Ctrl-F5
  • Opera: Clear the cache in Tools → Preferences

Definitions

  • <Template> -- the thing which does the work
* Templates -- transclude text from Category.
* Category: Templates
  • <Template/doc> -- matching documentation of the parameters available to the template (required or not) -- doc is always lower case -- Category: Template Documentation
  • <Template/Preload> -- A "clean copy" of the Template, for preloading into the Edit page by "<CreatArticle>" -- Category: Template Preloads
  • Boilerplate<Template> -- matching instructions for gathering information and completing the template.
  • Help:Article Creation -- "Create new xxx" -- shortcut to creating articles -- calls "Preload" and "Boilerplate" -- uses the MediaWiki Extension "<CreateArticle>"
Boilerplates
Templates
The Template should always transclude the matching Template/doc and Preload files, which should also always be transcluded into the Boilerplate page!



Eleazaros: Quick explain on how the tooltips work

Tooltip.js is just a pre-loader. core.js does most of the 'common' work. itemtooltip.js, questtooltip.js, etc... each handles parsing for the specific tags that they use.

In effect, the code grabs a rendered version of the page (much/most of the formatting stripped out), creates a work area called "tdf" (tdf2 for comparison stuff) in <document>, then assembles the tooltip.

The assembly is pretty simple. It parses through the HTML, via regular expressions, looking for the class="..." tags to extract the portions of information and format that it wants to use.

Now, when calling the proceedures, that is handled in the wiki templates by their class="..." usage, which is captured by the OnLoadHook part of the code. So if the wiki templates do not have the proper classes in use, the tooltips won't be activated to show.

That's it in a nutshell.

I figured you seemed very interested in what it was doing and how so I figured drop you a quick overview on it.

--Eleazaros 17:21, 10 January 2008 (PST)

Defining the parameters

  • These parameters are being passed along to the next level of template.
| amount=
ensures that the parameter has a value. There is a subtle difference between a parameter that is undefined, and a parameter with a blank value. This ensures that the parameter has a blank value. The whole line is creating a parameter for the call to Template:Tooltip which does a lot of common formatting for different kinds of tooltips. Basically, the input parameter is being passed along to the next level of template.
| mode = {{{mode|}}} =
| rename = {{{rename|}}} =
| arg = {{{arg|}}} =
| amount = {{{amount|}}} =
| name = {{s<includeonly></includeonly>ubst:PAGENAME}}
| icon = {{s<includeonly></includeonly>ubst:PAGENAME}}-icon <!-- preferably a GENERIC icon -->
| disambigpage = {{s<includeonly></includeonly>ubst:FULLPAGENAME}}
  • Imbed syntax: {{:Master (skill)|Master|mode=imlink}}
Mode -- Defined at Template: Tooltip
  • imlink = icon + text
  • link = text
  • im = icon ?

Goingbald: My actual understanding of tooltip templates

Actually, our templates Template:Item Tooltip, Template:Effect, Template:Skill & Template:Trait are all using a 2nd template Template:Tooltip which uses a 3rd template Template:Icon.

Parameters mode={{{mode|}}}, arg={{{arg|}}} & amount={{{amount|}}} seem only there to "pass" the parameter to the 2nd template Tooltip.

  • Item Tooltip uses all 3, arg to optionally override name, considered by template Tooltip (rename doesn't seem used, could be removed in template)
    • Template:Reward is a shortcut to not use prefix "Item:" but ends calling an item page, it uses arg, rename or plural to be passed as arg and uses by default "mode=imlink_plain"; if Item Tooltip was using imlink_plain instead of imlink by default (2nd line of template) and if we don't mind using as example {{:Item:Silver Token of the Wilds}} instead of {{Reward|Silver Token of the Wilds}}, Reward could be considered obsolete
    • Template:Barter is not calling any template or item page so that's why it lacks the ability to fetch the proper icon, but this allows to place the text as needed; if the float option would be directly in template Tooltip, Barter could be considered obsolete
  • Templates Effect, Skill & Trait are all
    • not using amount, that's OK not needed
    • using mode, still useful to control the look of the link
    • using rename, but I don't think of any situation where the text should be renamed for an effect, skill or trait, so those templates could be modified to remove this line
| rename       = {{{arg|{{{rename|}}}}}}
and change
| name         = {{#if:{{{arg|{{{rename|}}}}}}|{{{arg|{{{rename|}}}}}}|{{{name}}}}}
to pass the parameter as is
| name         = {{{name}}}
and remove this line in /doc pages, not used anyway in template
| arg={{{arg|}}}         Leave as is

-- Goingbald (talk) 02:37, 15 August 2013 (EDT)

Amphoras:

From what I remember, this seems right. The reason for the arg/rename thing is that originally, arg was there to change various things as necessary. It ended up that the only thing it was really used for was renaming stuff. So in some places rename was used instead.
There's so much half finished stuff going on with templates. The plan was to re-write how a lot of stuff worked, eg. using separate templates for different item types to cut down on the number of unused parameters all over the place. I actually created several of the new templates, but they were never put into use. I think the amount of work it would have taken to convert everything and make sure nothing broke was just too much, and people got busy with other stuff and it kindof fell away. I'm sure there was a load of stuff with traits, and auto-updating tables (currently if a trait changes, you need to make edits on several pages) I was working on to make things easier to maintain, but again it was a lot of work to get it going. Most of it was on the test wiki, and I think I saved it in various pages in my userspace as well if anyone is interested.
In summary, there's lots of stuff that was planned/started but wasn't quite finished, so we still see bits of it around that aren't being used properly yet. Amphoras (talkTalk to me!) 16:51, 18 August 2013 (EDT)