Fix cross references
This commit is contained in:
Rob Winch
@@ -93,7 +93,7 @@ Or in non-interactive mode:
|
||||
----
|
||||
====
|
||||
|
||||
TIP: Check out <<using-shell-customization-logging>> making logging to work
|
||||
TIP: Check out xref:using-shell-customization-logging.adoc[Logging] making logging to work
|
||||
better with shell apps.
|
||||
|
||||
[[using-spring-shell-your-first-command]]
|
||||
|
||||
@@ -4,8 +4,8 @@
|
||||
Throughout this documentation, we make references to configuring something by using
|
||||
annotations or programmatic examples.
|
||||
|
||||
NOTE: There are two annotation models, <<commands-registration-annotation, annotations>>
|
||||
referred to new annotation model, <<commands-registration-legacyannotation, legacy annotations>>
|
||||
NOTE: There are two annotation models, xref:using-shell-commands-registration-annotation.adoc[annotations]
|
||||
referred to new annotation model, xref:using-shell-commands-registration-legacyannotation.adoc[legacy annotations]
|
||||
referred to old legacy annotation model.
|
||||
|
||||
Old legacy annotation model mostly relates to use of `@ShellMethod` and `@ShellOption` and
|
||||
|
||||
@@ -57,7 +57,7 @@ Details of the error have been omitted. You can use the stacktrace command to pr
|
||||
----
|
||||
====
|
||||
|
||||
Information about currently unavailable commands is also used in the integrated help. See <<built-in-commands-help>>.
|
||||
Information about currently unavailable commands is also used in the integrated help. See xref:using-shell-commands-builtin-help.adoc[Help].
|
||||
|
||||
[TIP]
|
||||
====
|
||||
|
||||
@@ -7,7 +7,7 @@ accessing a web browser or any other rich UI application (such as a PDF viewer)
|
||||
be possible. This is why it is important that the shell commands are correctly self-documented, and this is where the `help`
|
||||
command comes in.
|
||||
|
||||
Typing `help` + `ENTER` lists all the commands known to the shell (including <<dynamic-command-availability,unavailable>> commands)
|
||||
Typing `help` + `ENTER` lists all the commands known to the shell (including xref:using-shell-commands-availability.adoc[unavailable] commands)
|
||||
and a short description of what they do, similar to the following:
|
||||
|
||||
====
|
||||
@@ -96,10 +96,10 @@ as a model.
|
||||
|`true` if showing groups is enabled. Otherwise, false.
|
||||
|
||||
|`groups`
|
||||
|The commands variables (see <<groupcommandinfomodel-variables>>).
|
||||
|The commands variables (see xref:using-shell-commands-builtin-help.adoc#groupcommandinfomodel-variables[GroupCommandInfoModel Variables]).
|
||||
|
||||
|`commands`
|
||||
|The commands variables (see <<commandinfomodel-variables>>).
|
||||
|The commands variables (see xref:using-shell-commands-builtin-help.adoc#commandinfomodel-variables[CommandInfoModel Variables]).
|
||||
|
||||
|`hasUnavailableCommands`
|
||||
|`true` if there is unavailable commands. Otherwise, false.
|
||||
@@ -114,7 +114,7 @@ as a model.
|
||||
|The name of a group, if set. Otherwise, empty.
|
||||
|
||||
|`commands`
|
||||
|The commands, if set. Otherwise, empty. Type is a multi value, see <<commandinfomodel-variables>>.
|
||||
|The commands, if set. Otherwise, empty. Type is a multi value, see xref:using-shell-commands-builtin-help.adoc#commandinfomodel-variables[CommandInfoModel Variables].
|
||||
|===
|
||||
|
||||
[[commandinfomodel-variables]]
|
||||
@@ -135,10 +135,10 @@ as a model.
|
||||
|The description of a command, if set. Otherwise, null.
|
||||
|
||||
|`parameters`
|
||||
|The parameters variables, if set. Otherwise empty. Type is a multi value, see <<commandparameterinfomodel-variables>>.
|
||||
|The parameters variables, if set. Otherwise empty. Type is a multi value, see xref:using-shell-commands-builtin-help.adoc#commandparameterinfomodel-variables[CommandParameterInfoModel Variables].
|
||||
|
||||
|`availability`
|
||||
|The availability variables (see <<commandavailabilityinfomodel-variables>>).
|
||||
|The availability variables (see xref:using-shell-commands-builtin-help.adoc#commandavailabilityinfomodel-variables[CommandAvailabilityInfoModel Variables]).
|
||||
|===
|
||||
|
||||
[[commandparameterinfomodel-variables]]
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
|
||||
|
||||
Command registration can define `InteractionMode` which is used to hide commands
|
||||
depending which mode shell is executing. More about that in <<using-shell-execution-interactionmode>>.
|
||||
depending which mode shell is executing. More about that in xref:using-shell-execution.adoc#using-shell-execution-interactionmode[Interaction Mode].
|
||||
|
||||
You can define it with `CommandRegisration`.
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ include::{snippets}/AnnotationRegistrationSnippets.java[tag=snippet1]
|
||||
|
||||
The only required attribute of the `@ShellMethod` annotation is its `value` attribute, which should have
|
||||
a short, one-sentence, description of what the command does. This lets your users
|
||||
get consistent help about your commands without having to leave the shell (see <<built-in-commands-help>>).
|
||||
get consistent help about your commands without having to leave the shell (see xref:using-shell-commands-builtin-help.adoc[Help]).
|
||||
|
||||
NOTE: The description of your command should be short -- no more than one or two sentences. For better
|
||||
consistency, it should start with a capital letter and end with a period.
|
||||
|
||||
@@ -19,7 +19,7 @@ be autowired. Default implementation of this supplier returns
|
||||
a new builder so you don't need to worry about its internal state.
|
||||
|
||||
IMPORTANT: Commands registered programmatically automatically
|
||||
add _help options_ mentioned in <<commands-helpoptions>>.
|
||||
add _help options_ mentioned in xref:using-shell-commands-helpoptions.adoc[Help Options].
|
||||
|
||||
If bean of this supplier type is defined then auto-configuration
|
||||
will back off giving you an option to redefine default functionality.
|
||||
|
||||
@@ -10,8 +10,8 @@ In the programmatic model, you use a more low level approach, defining command
|
||||
registrations (either as beans or by dynamically registering with a command catalog).
|
||||
|
||||
Starting from _3.1.x_ a better support for defining commands using
|
||||
<<commands-registration-annotation, annotations>> were added. Firstly because eventually standard
|
||||
package providing <<commands-registration-legacyannotation, legacy annotations>> will get deprecated
|
||||
xref:using-shell-commands-registration-annotation.adoc[annotations] were added. Firstly because eventually standard
|
||||
package providing xref:using-shell-commands-registration-legacyannotation.adoc[legacy annotations] will get deprecated
|
||||
and removed. Secondly so that we're able to provide same set of features than using underlying
|
||||
`CommandRegistration`. Creating new a annotation model allows us to rethink and modernise that
|
||||
part without breaking existing applications.
|
||||
|
||||
@@ -5,7 +5,7 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
|
||||
|
||||
In this section, we go through an actual command registration and leave command options
|
||||
and execution for later in a documentation. You can find more detailed info in
|
||||
<<appendix-tech-intro-registration>>.
|
||||
xref:appendices-techical-intro-registration.adoc[Command Registration].
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -65,4 +65,4 @@ include::{snippets}/CompletionSnippets.java[tag=anno-method]
|
||||
== Command-Line
|
||||
|
||||
Command-line completion currently only support _bash_ and is documented
|
||||
in a built-in `completion` command <<built-in-commands-completion>>.
|
||||
in a built-in `completion` command xref:using-shell-commands-builtin-completion.adoc[Completion].
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
|
||||
|
||||
When you use <<using-shell-components-ui>> to build something that involves
|
||||
When you use xref:using-shell-components-ui.adoc[Flow Components] to build something that involves
|
||||
use of a multiple components, your implementation may become a bit cluttered.
|
||||
To ease these use cases, we added a
|
||||
`ComponentFlow` that can hook multiple component executions together
|
||||
|
||||
@@ -28,5 +28,5 @@ The context object is `ConfirmationInputContext`. The following table describes
|
||||
|The default value -- either `true` or `false`.
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<textcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
@@ -31,5 +31,5 @@ The context object is `MultiItemSelectorContext`. The following table describes
|
||||
|The visible items, where rows contain maps of name, selected, on-row, and enabled items.
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<selectorcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#selectorcomponentcontext-template-variables[SelectorComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
@@ -24,5 +24,5 @@ The context object is `PathInputContext`. The following table describes its cont
|
||||
|Key |Description
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<textcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
@@ -15,7 +15,7 @@ include::{snippets}/UiComponentSnippets.java[tag=snippet9]
|
||||
====
|
||||
|
||||
NOTE: Logic for search is passed as is into algorithms documented
|
||||
in <<appendix-tech-intro-searchalgorithm>>.
|
||||
in xref:appendices-techical-intro-searchalgorithm.adoc[Search Algorithms].
|
||||
|
||||
The following image shows typical output from a path search component:
|
||||
|
||||
@@ -32,5 +32,5 @@ The context object is `PathSearchContext`. The following table describes its con
|
||||
|The items available for rendering search results.
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<textcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
@@ -31,7 +31,7 @@ The context object is `SingleItemSelectorContext`. The following table describes
|
||||
|The visible items, where rows contains maps of name and selected items.
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<selectorcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#selectorcomponentcontext-template-variables[SelectorComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
You can pre-select an item by defining it to get exposed. This is
|
||||
|
||||
@@ -40,5 +40,5 @@ The context object is `StringInputContext`. The following table lists its contex
|
||||
|`true` if a mask character is set. Otherwise, false.
|
||||
|
||||
|`model`
|
||||
|The parent context variables (see <<textcomponentcontext-template-variables>>).
|
||||
|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
|
||||
|===
|
||||
|
||||
@@ -19,7 +19,7 @@ Built-in components generally follow this logic:
|
||||
. Exit.
|
||||
. Render the final status of a component state.
|
||||
|
||||
NOTE: <<using-shell-components-flow>> gives better interface for defining the flow of
|
||||
NOTE: xref:using-shell-components-flow.adoc[Flow] gives better interface for defining the flow of
|
||||
components that are better suited for defining interactive command flows.
|
||||
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Spring Shell supports these via it's theming framework which contains two parts,
|
||||
firstly _styling_ can be used to change text type and secondly _figures_ how
|
||||
some characters are shown. These two are then combined together as a _theme_.
|
||||
|
||||
More about _theming_ internals, see <<appendix-tech-intro-theming>>.
|
||||
More about _theming_ internals, see xref:appendices-techical-intro-theming.adoc[Theming].
|
||||
|
||||
NOTE: Default theme is named `default` but can be change using property
|
||||
`spring.shell.theme.name`. Other built-in theme named `dump` uses
|
||||
|
||||
@@ -14,7 +14,7 @@ simple command-line tool without requiring customization.
|
||||
|
||||
Currently, interactive mode is entered if any command line options are passed when starting
|
||||
or running a shell from a command line. This works especially well when a shell application
|
||||
is compiled with <<native>>.
|
||||
is compiled with xref:using-shell-building.adoc#native[Native Support].
|
||||
|
||||
Some commands may not have any useful meanings when they run in interactive mode
|
||||
or (conversely) in non-interactive mode. For example, a built-in `exit` command would
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
|
||||
|
||||
Having a default value for an option is somewhat related to
|
||||
<<using-shell-options-optional>>, as there are cases where you
|
||||
xref:using-shell-options-optional.adoc[Optional Value], as there are cases where you
|
||||
may want to know if the user defined an option and change behavior
|
||||
based on a default value:
|
||||
|
||||
|
||||
@@ -5,6 +5,6 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
|
||||
|
||||
Framework provides a build-in views which are documented below.
|
||||
|
||||
TIP: To learn more about views, see <<appendix-tui-view>>.
|
||||
TIP: To learn more about views, see xref:appendices-tui-view.adoc[View].
|
||||
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@ NOTE: Feature is experimental and subject to breaking changes until foundation
|
||||
|
||||
_Terminal UI Framework_ is a toolkit to build rich console apps. This section is
|
||||
for those using existing features as is. If you're planning to go deeper possibly
|
||||
creating your own components <<appendix-tech-intro-tui>> provides more detailed
|
||||
creating your own components xref:appendices-tui.adoc[Terminal UI] provides more detailed
|
||||
documentation.
|
||||
|
||||
TIP: Catalog sample is a good place to study a real application <<appendix-tui-catalog>>.
|
||||
TIP: Catalog sample is a good place to study a real application xref:appendices-tui-catalog.adoc[Catalog App].
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user