From 2fe63367c6489293221cc626da62fbaddc2fd413 Mon Sep 17 00:00:00 2001 From: "Otavio R. Piske" Date: Sun, 18 Feb 2024 12:25:16 +0100 Subject: [PATCH] CAMEL-20410: documentation fixes for base files - Fixed grammar and typos - Fixed punctuation - Added and/or fixed links Signed-off-by: Otavio R. Piske --- .../partials/component-configure-options.adoc | 38 +++++++++++-------- .../partials/component-endpoint-options.adoc | 12 +++--- 2 files changed, 29 insertions(+), 21 deletions(-) diff --git a/docs/components/modules/ROOT/partials/component-configure-options.adoc b/docs/components/modules/ROOT/partials/component-configure-options.adoc index a58fbb4864e5b..11ce420e2c6b9 100644 --- a/docs/components/modules/ROOT/partials/component-configure-options.adoc +++ b/docs/components/modules/ROOT/partials/component-configure-options.adoc @@ -8,28 +8,36 @@ Camel components are configured on two separate levels: === Configuring Component Options -The component level is the highest level which holds general and common configurations that are inherited by the endpoints. -For example a component may have security settings, credentials for authentication, urls for network connection and so forth. +At the component level, you set general and shared configurations that are, then, inherited by the endpoints. It is the highest configuration level. -Some components only have a few options, and others may have many. Because components typically have pre configured defaults -that are commonly used, then you may often only need to configure a few options on a component; or none at all. +For example, a component may have security settings, credentials for authentication, urls for network connection and so forth. -Configuring components can be done with the xref:manual::component-dsl.adoc[Component DSL], -in a configuration file (application.properties|yaml), or directly with Java code. +Some components only have a few options, and others may have many. +Because components typically have pre-configured defaults that are commonly used, then you may often only need to configure a few options on a component; or none at all. + +You can configure components using: + +* the xref:manual::component-dsl.adoc[Component DSL]. +* in a configuration file (`application.properties`, `*.yaml` files, etc). +* directly in the Java code. === Configuring Endpoint Options -Where you find yourself configuring the most is on endpoints, as endpoints often have many options, which allows you to -configure what you need the endpoint to do. The options are also categorized into whether the endpoint is used as consumer (from) -or as a producer (to), or used for both. +You usually spend more time setting up endpoints because they have many options. +These options help you customize what you want the endpoint to do. +The options are also categorized into whether the endpoint is used as a consumer (_from_), as a producer (_to_), or both. -Configuring endpoints is most often done directly in the endpoint URI as path and query parameters. You can also use -the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and xref:manual::dataformat-dsl.adoc[DataFormat DSL] +Configuring endpoints is most often done directly in the endpoint URI as _path_ and _query_ parameters. +You can also use the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and xref:manual::dataformat-dsl.adoc[DataFormat DSL] as a _type safe_ way of configuring endpoints and data formats in Java. -A good practice when configuring options is to use xref:manual::using-propertyplaceholder.adoc[Property Placeholders], -which allows to not hardcode urls, port numbers, sensitive information, and other settings. -In other words placeholders allows to externalize the configuration from your code, and gives more flexibility and reuse. +A good practice when configuring options is to use xref:manual::using-propertyplaceholder.adoc[Property Placeholders]. + +Property placeholders provide a few benefits: + +* They help prevent using hardcoded urls, port numbers, sensitive information, and other settings. +* They allow externalizing the configuration from the code. +* They help the code to become more flexible and reusable. -The following two sections lists all the options, firstly for the component followed by the endpoint. +The following two sections list all the options, firstly for the component followed by the endpoint. // component-configure options: END diff --git a/docs/components/modules/ROOT/partials/component-endpoint-options.adoc b/docs/components/modules/ROOT/partials/component-endpoint-options.adoc index c69eb1eec4b66..623fb3f383023 100644 --- a/docs/components/modules/ROOT/partials/component-endpoint-options.adoc +++ b/docs/components/modules/ROOT/partials/component-endpoint-options.adoc @@ -32,7 +32,7 @@ The {doctitle} endpoint is configured using URI syntax: {syntax} ---- -with the following path and query parameters: +With the following _path_ and _query_ parameters: === Path Parameters ({pathparametercount} parameters) @@ -54,7 +54,7 @@ endif::[] === Query Parameters ({queryparametercount} parameters) ifeval::[{queryparametercount} == 0] -The {doctitle} endpoint has no query parameters. +The {doctitle} endpoint has no _query_ parameters. endif::[] ifeval::[{queryparametercount} != 0] @@ -70,7 +70,7 @@ ifeval::[{apicount} != 0] == API Parameters ({apicount} APIs) -The {doctitle} endpoint is an API based component and has additional parameters based on which API name and API method is used. +The {doctitle} endpoint is an API-based component and has additional parameters based on which API name and API method is used. The API name and API method is located in the endpoint URI as the `{apiSyntax}` path parameters: [subs='+attributes'] @@ -110,8 +110,8 @@ The {apiname} API is defined in the syntax as follows: {scheme}:{apiname}/methodName?[parameters] ------ -The {methodcount} method(s) is listed in the table below, followed by detailed syntax for each method. -(API methods can have a shorthand alias name which can be used in the syntax instead of the name) +The {methodcount} method(s) is(are) listed in the table below, followed by detailed syntax for each method. +(API methods can have a shorthand _alias_ name which can be used in the syntax instead of the name) [width="100%",cols="2,2,6a",options="header"] |=== @@ -144,7 +144,7 @@ In addition to the parameters above, the {name} API can also use any of the <<#_ Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header. The message header name must be of the format `Camel{pascalcasescheme}.parameter`. -The `inBody` parameter overrides message header, i.e. the endpoint parameter `inBody=myParameterNameHere` +The `inBody` parameter overrides message header, i.e., the endpoint parameter `inBody=myParameterNameHere` would override a `Camel{pascalcasescheme}.myParameterNameHere` header. %endif::[]