Page History

...

About Headings

This section refers to: Notation Guide >> Headings.

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.

Try to start each page with some introductory text, to separate the page title from the rest of content.

Likewise, try to have some content between all page headings. Avoid placing headings one after the other.

Document sections

Headings can help you divide your document in sections, subsections, sub-subsections and so forth.

Advantages

Your document becomes more organized.

Disadvantages

Too many headings can fragment the text.

Headings capitalization

Try to use 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 capitalization styles, we emphasize the importance of bigger headings.

Avoid skipping headers

The headers form an outline for the page. When writing term papers, it is not a good practice to skip outline levels. When writing hypertext, it is not a good practice to skip heading levels either. Try not to skip from a h2 to a h4.

...

About Headings

This section refers to: Notation Guide >> Headings.

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.

Try to start each page with some introductory text, to separate the page title from the rest of content.

Likewise, try to have some content between all page headings. Avoid placing headings one after the other.

Document sections

Headings can help you divide your document in sections, subsections, sub-subsections and so forth.

Advantages

Your document becomes more organized.

Disadvantages

Too many headings can fragment the text.

Headings capitalization

Try to use 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 capitalization styles, we emphasize the importance of bigger headings.

Avoid skipping headers

The headers form an outline for the page. When writing term papers, it is not a good practice to skip outline levels. When writing hypertext, it is not a good practice to skip heading levels either. Try not to skip from a h2 to a h4.

More on Text Effects

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.

Monospaced should be used to files, tags, and methods, like struts.xml, <xmltag />, and execute. Class and Interface names may be left in normal face, like Action and Interceptor.

A panel should be preferred to a block quote.

The color fonts should be avoided or used only with great care. Some people have difficulty seeing some colors, and the colors may not be apparent if the page is printed.

Text Breaks

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.

Lists

This section refers to: Notation Guide >> Lists.

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

Ordered list should be used when numbering the items is important. Otherwise, prefer unordered lists.

• This is an unordered list in star notation;
• Items can have sub-items
  • That can have sub-items
    • That can have sub-items ...
      • What is the limit?
• Mixing ordered and unordered lists is possible:
  1. One;
  2. Two;
  3. Three.

Images

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.

Monospaced should be used to files, tags, and methods, like struts.xml, <xmltag />, and execute. Class and Interface names may be left in normal face, like Action and Interceptor.

A panel should be preferred to a block quote.

The color fonts should be avoided or used only with great care. Some people have difficulty seeing some colors, and the colors may not be apparent if the page is printed.

Text Breaks

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.

...

Images and Notation Guide >> Misc.

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

Images can be 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 original or public domain work, or the author has donated the image to the foundation.

Example: Image Added

Icons

Use , , , and to bullet important one-liners. Use to highlight cross references.

Used carefully, icons can make the content easier to read and understand.

However, if icons are overused, they lose impact (and can make a page look like a ransom note).

Casual icons like and should be used with care or avoided.

Tables

This section refers to: Notation Guide >> ListsTables.

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

Ordered list should be used when numbering the items is important. Otherwise, prefer unordered lists.

• This is an unordered list in star notation;
• Items can have sub-items
  • That can have sub-items
    • That can have sub-items ...
      • What is the limit?
• Mixing ordered and unordered lists is possible:
  1. One;
  2. Two;
  3. Three.

Images

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 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 original or public domain work, or the author has donated the image to the foundation.

Example: Image Removed

Icons

Use , , , and to bullet important one-liners. Use to highlight cross references.

Used carefully, icons can make the content easier to read and understand.

However, if icons are overused, they lose impact (and can make a page look like a ransom note).

Casual icons like and should be used with care or avoided.

Tables

This section refers to: Notation Guide >> Tables.

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

Tables are very useful when lists just don't do it. Meaning: don't write a table when a list suffices. Tables are more organized, because you can align the text in columns. Since the markup text for tables in Confluence is not easy to read, complex and big tables can be hard to maintain.

Advanced Formatting

This section refers to: Notation Guide >> Advanced Formatting.

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

Try to give all panels and {code} blocks meaningful titles. People scan the pages looking for likely tips and examples.

Avoid generic titles like "Warning" or "Example". Style the headings like they were h3. or smaller.

When a panel contains a file or a class, the panel title should refer to the filename or classname.

Try to specify the language for {code} blocks.

...

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

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

Tables are very useful when lists just don't do it. Meaning: don't write a table when a list suffices. Tables are more organized, because you can align the text in columns. Since the markup text for tables in Confluence is not easy to read, complex and big tables can be hard to maintain.

Advanced Formatting

This section refers to: Notation Guide >> Advanced Formatting.

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

Try to give all panels and {code} blocks meaningful titles. People scan the pages looking for likely tips and examples.

Avoid generic titles like "Warning" or "Example". Style the headings like they were h3. or smaller.

When a panel contains a file or a class, the panel title should refer to the filename or classname.

Try to specify the language for {code} blocks.

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

Try to use snippets for code blocks whenever possible!

Avoid tabs in code blocks, use two spaces instead. Long lines should be formatted to fit in a 800x600 resolution screen, without resorting to horizontal scrolling.

A typical example of noformat would be the command line statements to compile and run the code above.

Either the code or noformat block can be used to represent command line windows. The terminal notation ({$}} should be used to represent a system prompt.

$ javac HelloWorld.java

$ java HelloWorld
Hello, World!

Change Happens

Anyone who has worked with databases knows the value of normalizing the schema. Ideally, we want to store each fact exactly once, and then use query system to retrieve that fact whereever it is needed. If we store a fact once, we only need to update it once, and we avoid inconsistencies in our data set.

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 redundancy (without sacrificing ease of use).

Single sourcing with snippets

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 any file for reuse. The macro fetches those snippets from a repository and merges the content into the documentation.

Example snippet usage

{snippet:id=example|lang=xml|javadoc=true|url=struts2/core/src/main/java/org/apache/struts2/components/If.java}

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

A 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 http://svn.apache.org/repos/asf/struts/struts2/trunk/apps/showcase/src/main/java/org/apache/struts2/showcase/DateAction.java the two possible methods are:

{snippet:lang=java|url=struts2/apps/showcase/src/main/java/org/apache/struts2/showcase/DateAction.java}
{snippet:lang=java|url=struts2/apps.showcase.src.main.java.org.apache.struts2.showcase.DateAction}

To include a snippet from https://svn.apache.org/repos/asf/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/validator/validators/StringLengthFieldValidator.java the two possible methods are:

{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.validator.validators.StringLengthFieldValidator}
{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.validator/validators/StringLengthFieldValidator.java}

The list of available prefixes:

Try to use snippets for code blocks whenever possible!

Avoid tabs in code blocks, use two spaces instead. Long lines should be formatted to fit in a 800x600 resolution screen, without resorting to horizontal scrolling.

A typical example of noformat would be the command line statements to compile and run the code above.

Either the code or noformat block can be used to represent command line windows. The terminal notation ({$}} should be used to represent a system prompt.

$ javac HelloWorld.java

$ java HelloWorld
Hello, World!

Change Happens

Anyone who has worked with databases knows the value of normalizing the schema. Ideally, we want to store each fact exactly once, and then use query system to retrieve that fact whereever it is needed. If we store a fact once, we only need to update it once, and we avoid inconsistencies in our data set.

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 redundancy (without sacrificing ease of use).

Single sourcing with snippets

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 any file for reuse. The macro fetches those snippets from a repository and merges the content into the documentation.

Example snippet usage

{snippet:id=example|lang=xml|javadoc=true|url=struts2/core/src/main/java/org/apache/struts2/components/If.java}

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

A URL must start with a valid prefix. Currently there are two valid prefixes that are useful for Struts documentation purposes.

• com.opensymphony.xwork2. (notice the period)
• struts2/ (notice the trailing slash)

Destination

Prefix
com.opensymphony.xwork2.	http://svn.opensymphony.com/svn/xwork/trunkapache.org/repos/asf/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/Image Removed
org.apache.struts2/.	http://svn.apache.org/repos/asf/struts/struts2/trunk/Image Removed

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

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.

...

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

...

Back:

...

Contributors Guide