Year of the Dragon: Through May 28th, claim free Expansion Pack (excluding Vecna Unleashed) or a Greater Elixir of Discovery! Speak to Xatheral in the Hall of Heroes. edit

Thank you for your patience while we continue to upgrade DDOwiki to the latest MediaWiki LTS version. If you find any errors on the site, please visit the Discord chat server and let us know.

Game mechanicsNewbie guideIn developmentDDO StoreSocial Media


ChallengesClassesCollectablesCraftingEnhancementsEpic DestiniesFavorFeats

GlossaryItemsMapsMonstersPlacesQuestsRacesReincarnationSkillsSpells


Please create an account or log in to remove ads, build a reputation, and unlock more editing privileges and then visit DDO wiki's IRC Chat/Discord if you need any help!

User:Corgrind/Coding

From DDO wiki
Jump to navigation Jump to search
AboutMe My Maps Coding Sandbox Talk


I found that some of the updates I like to do require handling templates. So I look into existing templates, trying to learn the rules.

My standards for coding usually follow these lines (and more):

  • Don't be repetitive in code text - use loops or sub functions (templates)
  • Be exhaustive in comments if possible
  • Create readable code
    • which is not always possible (see below)
  • Create reuseable code if possible
    • enabling a method to enforce standards
    • avoid recoding if an useable module exists
  • Strictly separate data and presentation
    • Don't enforce unchangeable formatting on data or intermediate level

Current project[edit]

Current goal is a quest list template controlled by a list of quest names instead of a category. This will be derived from the template T:quest list and shall replace the QTH/QTL/QTB templates.

First thing I encountered is a repetive use of XP formatting, so I went to the bottom of the T:Xpcolors template. I found that it is enforcing popups and bold numbers.

I already created a sub template T:Xpcolors/subst which handles the base formatting difficulty independant: And I have learned:

  • Line breaks within the code can lead to unexpected <p> statements in the resulting HTML code. The only save positions are within the condition sections
    • When I think code is too unreadable I may add the "unfolded" code to the talk page
    • Same when I think some code has to be explained
  • the statement {{#switch: does not work properly when used with a parameter/default value {{{1|defVal}}}. The #default: path is always used when the parameter is empty
  • the statement {{#if: may not work correctly if the else section is not defined ("|" missing)

Please use the talk page if you have comments