|
| 1 | +--- |
| 2 | +# We use sentence case and present imperative tone |
| 3 | +title: "{{ replace .Name "-" " " | title }}" |
| 4 | +# Weights are assigned in increments of 100: determines sorting order |
| 5 | +weight: i00 |
| 6 | +# Creates a table of contents and sidebar, useful for large documents |
| 7 | +toc: false |
| 8 | +# Types have a 1:1 relationship with Hugo archetypes, so you shouldn't need to change this |
| 9 | +type: concept |
| 10 | +# Intended for internal catalogue and search, case sensitive: |
| 11 | +# Agent, N4Azure, NIC, NIM, NGF, NAP-DOS, NAP-WAF, NGINX One, NGINX+, Solutions, Unit |
| 12 | +product: |
| 13 | +--- |
| 14 | + |
| 15 | +[//]: # "These are Markdown comments to guide you through document structure. Remove them as you go, as well as any unnecessary sections." |
| 16 | +[//]: # "Use underscores for _italics_, and double asterisks for **bold**." |
| 17 | +[//]: # "Backticks are for `monospace`, used sparingly and reserved mostly for executable names - they can cause formatting problems. Avoid them in tables: use italics instead." |
| 18 | + |
| 19 | +[//]: # "Begin each document with a sentence or two explaining what the purpose of the guide is, and what high-level actions to expect. No need to adhere precisely the example text given anywhere in this template." |
| 20 | + |
| 21 | +This guide provides an overview of < concept>, which is used <for/in> <action 1>, <action 2> and <action 3>. |
| 22 | + |
| 23 | +It is an example of a <other concept>, and is closely related to <third concept>. |
| 24 | + |
| 25 | +--- |
| 26 | + |
| 27 | +## Background |
| 28 | + |
| 29 | +[//]: # "Explain what the concept is. If possible, relate it to another commonly known concept or software." |
| 30 | +[//]: # "This relates the new idea to the reader using their existing knowledge, helping their understanding of it and thus what its purpose is in context." |
| 31 | + |
| 32 | +--- |
| 33 | + |
| 34 | +## Use cases |
| 35 | + |
| 36 | +[//]: # "Name the individual use case sections after the actual use case itself, e.g 'Route traffic between applications'" |
| 37 | + |
| 38 | +### Use case 1 |
| 39 | + |
| 40 | +[//]: # "A description for a use case should be a high level outline of a particular problem, then explain how the subject concept is the solution for the issue." |
| 41 | + |
| 42 | +[//]: # "If it helps, include a diagram of some kind. Ensure your description provides all the context required, however: a diagram is an aid to explain things, not a replacement." |
| 43 | + |
| 44 | +```mermaid |
| 45 | +# You can use Mermaid to draw diagrams in a codeblock with mermaid as the language. |
| 46 | +# Read their documentation for usage: https://mermaid.js.org/intro/ |
| 47 | +``` |
| 48 | + |
| 49 | +Starting from the <top/left> of the diagram, you can see that <thing> is connected to <other thing>: this relationship is established when configuring <parameter> as part of <file name>. |
| 50 | + |
| 51 | +[//]: # "End a particular use case section with links to other pages, such as instructional documentation, other concepts, or reference information (Such as API specifications)." |
| 52 | + |
| 53 | +- [Additional reading 1](some-external-link) |
| 54 | +- [Additional reading 2]({{< ref "/some/internal/link.md" >}}) |
| 55 | +- Additional reading 3 |
| 56 | + |
| 57 | +### Use case 2 |
| 58 | + |
| 59 | +--- |
| 60 | + |
| 61 | +## Conclusion |
| 62 | + |
| 63 | +[//]: # "Summarize everything that the reader will have learned by reading this entire concept document." |
| 64 | +[//]: # "It should fulfill the promise made by the introductory paragraph at the top of the document." |
| 65 | +[//]: # "Since each use case provides links to additional documents, you may not need to link to more," |
| 66 | +[//]: # "or even include the final 'See also' section." |
| 67 | + |
| 68 | +--- |
| 69 | + |
| 70 | +## See also |
| 71 | + |
| 72 | +[//]: # "Link to related documents, such as concepts, reference material or similar use cases." |
0 commit comments