Documentation Style Guide

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


First, we want the documentation to be both complete and concise. This is job one! The documentation should also be a quick but practical introduction to the framework, so newcomers can get started as easily as possible. To keep people coming back, the documenation documentation should also be a repository of the tips and tricks we use in our own applications, so that people can find it here instead of asking over and over again on the list.

Second, the documentation should be easy to maintain. Ideally, we should cover the detail of each topic once, and draw as much detail from the source code and examples as possible (using the snippet macro).

Third, the documentation should be text-book quality; if not in the first draft, then in the next. Don't hesitate to hack in a new page. Better that we have the page than we don't. (See Job One!) But, as time allows, we should try to make each page the best that it can be. A great many people access the documentation, and it's worth the effort to make the "documentation experience" productive and enjoyable.


  • Use as few words as possible. Instead of "but there are some quirks about it" try "but there are quirks".
  • If a list of items includes both a term and an explanation, consider using a table instead of bullets.
  • Avoid using "This" by itself. Instead of "This lets us" try "This strategy lets us".
    • Ask yourself: "This what?"
  • References to other wiki pages can be unqualified. Instead of For example: "See Documentation Style Guide page", try "See Documentation Style Guide."

Don't be smurfy!

A lot of API members use the term "action". We have


Use the Parent Page feature to create a hierarchy of pages. The parent pages are reflected in the "bread crumb" menu. If propertly properly used, parent pages can help browsers "visualize" the documenation documentation as an outline.

The root of the documentation is the "Home" page, which is also the "Welcome" page. The documnentation documentation is ordered into three main areas: Tutorials, FAQs, and Guides. Each area has a contents page, whose parent is Home. Other pages within each section can also serve as parents, to help organize the documentation into a coherent outline.


The Shortcut Link feature should be used for any external reference that may be used elsewhere.
Shortcuts being used include


A ticket in our issue tracker






A bookmark in our Key Technologies Primer


A class in the XWork Javadocs


A class in the Java Javadocs


A topic the Confluence help system

Please add new shortcuts as needed.




A ticket in our issue tracker




S2 Plugin Repository




The Struts 2 website



About Headings

(info) This section refers to: [Notation Guide >> Headings|section=headings@wiki].

About h1

Don't use h1. at the top of each page. The page title serves as the "top level header". This is not as obvious online, but it is very apparent when the documentation is exported to HTML or PDF.


titleHere we go again!

This segment is an example of overusing headings. This whole "Headings" section has so few paragraphs that it really should have been written in just one section. The "advantages" and "disadvantages" would be just as easy to render as a table.

Headings capitalization

Try to use intial initial capitals for h1 and h2 headers.

For h3 and smaller headings, try to capitalize only the first word, and any proper nouns.

By using different capilazation sytlescapitalization styles, we emphasize the importance of bigger headings.


titleToo many headings?

If you find yourself writting writing too many h2 headings in a single page, consider breaking the page into child pages.

More on Text Effects

(star) This section refers to: Notation Guide >> Text Effects.

Text effects like strong, emphasis, and inserted can be used in the usual way to denote important parts of a sentence.


Text Breaks

(star) This section refers to: Notation Guide >> Text Breaks.

Text breaks should not be used to format blocks on the screen. If there is an issue with the way paragraphs or headings are being rendered, we should customize the stylesheet.


(star) This section refers to: Notation Guide >> Lists.

Unordered lists should be created only with the * (star) notation.



(star) This section refers to: Notation Guide >> Images and Notation Guide >> Misc.

Avoid using external images for bullets or icons. Prefer the equivalents provided with Confluence.

Images can be inclued included by URL or annexing the binary to the page. Prefer annexing when possible, since URLs are subject to change.

Always observe copyright issues. Do not annex images unless it an orginal original or public domain work, or the author has donated the image to the foundation.

Example: Image Removed Image Added


Use (info), (question), (warning), and (tick) to bullet important one-liners. Use (lightbulb) to highlight cross references.



(star) This section refers to: Notation Guide >> Tables.

Prefer lists for single-value entries. Prefer tables for lists with multiple columns.


Advanced Formatting

(star) This section refers to: Notation Guide >> Advanced Formatting.

Panels should be used as needed. Try to select the right panel for the content.


Code Block
/** Hello World class. */
public class HelloWorld {
  /** Main method. */
  public static void main(String[] args) {
    System.out.println("Hello, World!");

(tick) Try to use snippets for code blocks whenever possible!


To the extent possible, we want to "normalize" our technical documentation. Like a database, all technical documentation is subject to change. When change happens, we want the documentation to be as easy to update as possible. One way to do that is to try and minimize redudency redundancy (without sacrificing ease of use).


The "holy grail" of technical documentation is single sourcing. One way we try to single-source documentation is to pull content directly from the Javadocs and source code into the documentation.

Using a snippet macro, we are able to tag portions of the Javadocs and source code any file for reuse. The macro fetches those snippets from the a repository and merges the content into the documentation.

titleUse the Source!

Before writing any new content, ask yourself if we could place the content in the repository in either one of the example applications or the Javadocs. Rather than contrive an example, can you pull a snippet from one of the applications? Rather than reiterate Javadoc, could we update the Javadoc and make it a snippet?

  • Javadoc
    • {snippet:id=javadoc|javadoc=true|url=org.apache.struts2.components.If}
  • Tag Attributes
    • {snippet:id=tagattributes|javadoc=false|url=struts2/docs/tags/If.html}


It is preferable to use snippets from the Struts example apps over Javadoc snippets for anything except plain text content as this ensures that the content's syntax has been validated.

Example snippet usage

Code Block
titleSnippet usage example

The language that the code block


Snippet Attributes


The name of the snippet (requiredoptional - defaults to "all", meaning the entire file).


The URL where the snippet can be found (required).



If true line numbers are displayed. Numbering always starts at 1.


lang=java would surround the snippet with {code:java}snippet{code}. If this snippet is simply text, don't include this parameter and the content will be printed outside of a code block.


If true, the content is within a Javadoc block. If this is set to true, then the preceeding "* " (asterisk-space) characters will be stripped before merging the content. Also, the content is assumed to be already HTML escaped and won't be escaped again.

All snippets are marked off by the pattern START SNIPPET: XXX and END SNIPPET: XXX where XXX is the name of the snippet that is assigned in the id attribute of the macro. The URL is typically a location that points to the project's source control contents. |

About URLs

As you probably noticed in the examples, there are several formats for URL patterns. A fully-qualified URL is always allowed, though that is often not practical. We've customized the macro to be a bit more intelligent with the URL attribute.

URL must start with a valid prefix. There are two types of prefixes:

  • com.opensymphony.xwork2. Notice the period. This syntax is better when you want to include content from a class because they allow you to use the fully qualified classname as the URL.
  • struts2/ Notice the trailing slash. This syntax better when you want to include content content from non-class files such as xml or properties files. They may also be needed if a class based prefix for a sub-project has not be setup.

To include a snippet from the two possible methods are:

Code Block


To include a snippet from the two possible methods are:

Code Block


The list of available prefixes:

About snippet markers

When possible, all snippet markers should be in comment blocks. How they are commented depends on where the snippet is being embedded.


If the snippet is embedded in Javadocs, within Javadoc comments use HTML comments to declare the snippet as they won't render in the Javadocs. For XML examples in Javadocs can be tricky. (See Timer Interceptor for an example.). Javadocs want to use the <pre> tag, but you don't want that tag in the snipped content.One technique is to

When using the <pre> tag within Javadoc comments embed the snippet markers inside the <pre> tag.

Code Block
titleSnipping XML examples from Javadoc content
* <pre>
 * <!-- START SNIPPET: example -->
 * &lt;!-- records only the action's execution time --&gt;
 * &lt;action name="someAction" class="com.examples.SomeAction"&gt;
 *     &lt;interceptor-ref name="completeStack"/&gt;
 *     &lt;interceptor-ref name="timer"/&gt;
 *     &lt;result name="success"&gt;good_result.ftl&lt;/result&gt;
 * &lt;/action&gt;
 * <!-- END SNIPPET: example -->


* </pre>

A <pre> tag within a Javadoc comment would be escaped and rendered as part of the snippet. See for an complete example.

Back: Contributors Guide