FANDOM


Policysign

Is a guideline on AddOn Studio Wiki.

  • Feel free to update the page as needed.
  • See Category:Guidelines for a list of guideline articles.

Documentation Structure Edit

The following categories represent the various places documentation and other content should be placed as related to WoW development. WoW development covers more than just the game client, and not everything here is user interface customization or macro related.

Major Reference Sections Edit

  • WoW development
    • UI Customization - major category primarily covering the game client public APIs and facilites
      • WoW AddOn - this section is a reference for AddOn development itself, including file formats, rules, and getting started
      • XML UI - this section is a reference and includes all the Ui XML related documenation, including widget docs as related to XML
      • Widget API - this section is a reference for all of the Lua interface for the Widgets, only
      • WoW API - this section is a reference for all of the Lua interface related free standing WoW API functions and conventions, only
      • WoW Lua - this section is a reference for WoW version Lua runtime and any custom functions or conventions
      • Event API - this section is a reference for all of the game events
      • Macro API - this seciton is a reference for Macro and slash command development
      • CVars - this section is a reference for all the game client 'console variables'
    • Web API - major category for the public Community Web Platform and any other web related factilites

Other General Sections Edit

  • WoW development
    • WoW HOWTOs - various articles that could be about anything relating to WoW Development and getting something done
    • Snippets - cut-and-paste functions that you can use in your addons, submitted by wiki contributors
    • UI Tech - contains various documents that describe the UI technical details for the WoW UI system

Policies Edit

In most cases this has been taken care of for you, by using the {{templates}} already created for each major category.

  • Please do not create blank stubs just to get rid of red links. We want the red links there to know that it may need documentation!

Different types of pages Edit

Please reference the major and general doumentation categories in API Documentation Structure above. Just following exising conventions for these and other categories, and noticing how these pages were done is usually the best way, and should be your primary self-documented guide for adding and editing wow wiki development content.

Below is a list of some of the different types of pages, with a few additional guidelines.

Widget reference Edit

Guidelines for editing the UI Customization Widget API reference pages.

  • Only document the a widget method in its own base class. Do not document the same method in all inherited widgets.
  • Document new methods or other changes in the Widget API page first, even if thats the only place.
  • Use Help:Widget method articles as a basis for the page.
  • The 'UISUMMARY WidgetName', e.g. [[UISUMMARY EditBox]] is obsolete, use a 'UIOBJECT WidgetName' page instead.
  • Use the {{wgapi}} template for referncing links. Prefrer method links to the Widget API page from outside the widget pages.

A Widget page Edit

  • Name the page 'UIOBJECT WidgetName', like 'UIOBJECT Slider'.
  • Place {{widget|WidgetName}} at the top of the page (the boilerplate already has it).

A Widget Method page Edit

  • Name the page 'API WidgetName FunctionName', like 'API Slider SetValueStep'.
  • Place {{widgetmethod|WidgetName}} at the top of the page (the boilerplate already has it).

WoW API page Edit

Adding and editing function links:

  • Do not place a function under several headings unless you really feel it belongs there. See previous point.
  • Basic link syntax: [[API DisableAddOn|DisableAddOn]](index or "addonname")   →   DisableAddOn(index or "addonname")
  • Don't just say "NEW!" or "REMOVED!". Say in which version! It may be obvious to you when you write it, since it's the current one, but the page has to make sense three months from now, too. And more.

Regular API function pages Edit

Global, honest-to-god APIs, e.g. [UnitName], [AcceptDuel], [GetAddOnDependencies]

Learning about undocumented functions Edit

So when you can't find a reference to learn how a WoW API works, what to do?

  • Ask yourself if the examples really cover everything you need to know:
    • What happens on failure? Does the function return nil or false?
    • That logical test you see, is the function returning 1 or true? It might make a difference to others.
    • Which parameters can be left as nil?
  • TEST your questions. Either by experimenting with the API in an AddOn of yours, or, perhaps easier, use an in-game Lua editor like myDebug!
  • Please help the rest of us and type your findings into the wiki :-)

Someone else might have done the hard work without sharing already; if you have a bunch of AddOns installed, try searching in them to see if they use the API. It might tell you more.

FrameXML function pages Edit

These are the "UI" tagged functions, e.g. [ChatFrame_AddChannel], [ToggleBackpack]

Other FrameXML pages Edit

For instance [API AuctionFrameAuctions.duration] et al.

Data type pages Edit

  • Name the page typeName (no prefix to make it easier to link)
  • Place {{wowapitype}} at the top of the page.
  • Not every argument deserves to be described as a stand-alone data type. E.g. if it's just a 1--n index that every novice hacker can grasp, chances are, it doesn't.

User-defined function pages Edit

UI Technical Details pages Edit

See also Edit

Community content is available under CC-BY-SA unless otherwise noted.