Reorganize Painless doc structure (#42303)

Author: jdconrad

docs/painless/index.asciidoc

@@ -3,7 +3,7 @@
 
 include::../Versions.asciidoc[]
 
-include::painless-getting-started.asciidoc[]
+include::painless-guide.asciidoc[]
 
 include::painless-lang-spec.asciidoc[]
 

docs/painless/painless-contexts.asciidoc

@@ -54,6 +54,4 @@ specialized code may define new ways to use a Painless script.
                                     | {xpack-ref}/transform-script.html[Elasticsearch Documentation]
 |====
 
-include::painless-contexts/painless-context-examples.asciidoc[]
-
 include::painless-contexts/index.asciidoc[]

docs/painless/painless-contexts/index.asciidoc

@@ -1,3 +1,5 @@
+include::painless-context-examples.asciidoc[]
+
 include::painless-ingest-processor-context.asciidoc[]
 
 include::painless-update-context.asciidoc[]

docs/painless/painless-description.asciidoc renamed to docs/painless/painless-guide.asciidoc

@@ -1,11 +1,14 @@
+[[painless-guide]]
+== Painless Guide
+
 _Painless_ is a simple, secure scripting language designed specifically for use
 with Elasticsearch. It is the default scripting language for Elasticsearch and
-can safely be used for inline and stored scripts. For a detailed description of
-the Painless syntax and language features, see the
-{painless}/painless-lang-spec.html[Painless Language Specification].
+can safely be used for inline and stored scripts. For a jump start into
+Painless, see <<painless-walkthrough, A Brief Painless Walkthrough>>. For a
+detailed description of the Painless syntax and language features, see the
+<<painless-lang-spec, Painless Language Specification>>.
 
-[[painless-features]]
-You can use Painless anywhere scripts can be used in Elasticsearch. Painless
+You can use Painless anywhere scripts are used in Elasticsearch. Painless
 provides:
 
 * Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
@@ -18,7 +21,9 @@ complete list of available classes and methods.
 * Optional typing: Variables and parameters can use explicit types or the
 dynamic `def` type.
 
-* Syntax: Extends Java's syntax to provide http://groovy-lang.org/index.html[
-Groovy-style] scripting language features that make scripts easier to write.
+* Syntax: Extends a subset of Java's syntax to provide additional scripting
+language features.
 
 * Optimizations: Designed specifically for Elasticsearch scripting.
+
+include::painless-guide/index.asciidoc[]

docs/painless/painless-guide/index.asciidoc

@@ -0,0 +1,7 @@
+include::painless-walkthrough.asciidoc[]
+
+include::painless-method-dispatch.asciidoc[]
+
+include::painless-debugging.asciidoc[]
+
+include::painless-execute-script.asciidoc[]

docs/painless/painless-debugging.asciidoc renamed to docs/painless/painless-guide/painless-debugging.asciidoc

@@ -0,0 +1,30 @@
+[[modules-scripting-painless-dispatch]]
+=== How painless dispatches functions
+
+Painless uses receiver, name, and https://en.wikipedia.org/wiki/Arity[arity]
+for method dispatch. For example, `s.foo(a, b)` is resolved by first getting
+the class of `s` and then looking up the method `foo` with two parameters. This
+is different from Groovy which uses the
+https://en.wikipedia.org/wiki/Multiple_dispatch[runtime types] of the
+parameters and Java which uses the compile time types of the parameters.
+
+The consequence of this that Painless doesn't support overloaded methods like
+Java, leading to some trouble when it whitelists classes from the Java
+standard library. For example, in Java and Groovy, `Matcher` has two methods:
+`group(int)` and `group(String)`. Painless can't whitelist both of these methods
+because they have the same name and the same number of parameters. So instead it
+has `group(int)` and `namedGroup(String)`.
+
+We have a few justifications for this different way of dispatching methods:
+
+1. It makes operating on `def` types simpler and, presumably, faster. Using
+receiver, name, and arity means that when Painless sees a call on a `def` object it
+can dispatch the appropriate method without having to do expensive comparisons
+of the types of the parameters. The same is true for invocations with `def`
+typed parameters.
+2. It keeps things consistent. It would be genuinely weird for Painless to
+behave like Groovy if any `def` typed parameters were involved and Java
+otherwise. It'd be slow for it to behave like Groovy all the time.
+3. It keeps Painless maintainable. Adding the Java or Groovy like method
+dispatch *feels* like it'd add a ton of complexity which'd make maintenance and
+other improvements much more difficult.

docs/painless/painless-execute-script.asciidoc renamed to docs/painless/painless-guide/painless-execute-script.asciidoc

@@ -1,10 +1,5 @@
-[[painless-getting-started]]
-== Getting Started with Painless
-
-include::painless-description.asciidoc[]
-
-[[painless-examples]]
-=== Painless Examples
+[[painless-walkthrough]]
+=== A Brief Painless Walkthrough
 
 To illustrate how Painless works, let's load some hockey stats into an Elasticsearch index:
 
@@ -121,7 +116,7 @@ GET hockey/_search
 
 
 [float]
-===== Missing values
+==== Missing values
 
 `doc['field'].value` throws an exception if
 the field is missing in a document.
@@ -198,7 +193,7 @@ POST hockey/_update/1
 ==== Dates
 
 Date fields are exposed as
-`ReadableDateTime`, so they support methods like `getYear`, `getDayOfWeek` 
+`ZonedDateTime`, so they support methods like `getYear`, `getDayOfWeek`
 or e.g. getting milliseconds since epoch with `getMillis`. To use these
 in a script, leave out the `get` prefix and continue with lowercasing the
 rest of the method name. For example, the following returns every hockey 
@@ -365,38 +360,3 @@ Note: all of the `_update_by_query` examples above could really do with a
 {ref}/query-dsl-script-query.html[script query] it wouldn't be as efficient
 as using any other query because script queries aren't able to use the inverted
 index to limit the documents that they have to check.
-
-[[modules-scripting-painless-dispatch]]
-=== How painless dispatches functions
-
-Painless uses receiver, name, and https://en.wikipedia.org/wiki/Arity[arity]
-for method dispatch. For example, `s.foo(a, b)` is resolved by first getting
-the class of `s` and then looking up the method `foo` with two parameters. This
-is different from Groovy which uses the
-https://en.wikipedia.org/wiki/Multiple_dispatch[runtime types] of the
-parameters and Java which uses the compile time types of the parameters.
-
-The consequence of this that Painless doesn't support overloaded methods like
-Java, leading to some trouble when it whitelists classes from the Java
-standard library. For example, in Java and Groovy, `Matcher` has two methods:
-`group(int)` and `group(String)`. Painless can't whitelist both of these methods
-because they have the same name and the same number of parameters. So instead it
-has `group(int)` and `namedGroup(String)`.
-
-We have a few justifications for this different way of dispatching methods:
-
-1. It makes operating on `def` types simpler and, presumably, faster. Using
-receiver, name, and arity means that when Painless sees a call on a `def` object it
-can dispatch the appropriate method without having to do expensive comparisons
-of the types of the parameters. The same is true for invocations with `def`
-typed parameters.
-2. It keeps things consistent. It would be genuinely weird for Painless to
-behave like Groovy if any `def` typed parameters were involved and Java
-otherwise. It'd be slow for it to behave like Groovy all the time.
-3. It keeps Painless maintainable. Adding the Java or Groovy like method
-dispatch *feels* like it'd add a ton of complexity which'd make maintenance and
-other improvements much more difficult.
-
-include::painless-debugging.asciidoc[]
-
-include::painless-execute-script.asciidoc[]

docs/painless/painless-guide/painless-method-dispatch.asciidoc

@@ -17,38 +17,4 @@ into Java Virtual Machine (JVM) byte code and executed against a standard JVM.
 This specification uses ANTLR4 grammar notation to describe the allowed syntax.
 However, the actual Painless grammar is more compact than what is shown here.
 
-include::painless-comments.asciidoc[]
-
-include::painless-keywords.asciidoc[]
-
-include::painless-literals.asciidoc[]
-
-include::painless-identifiers.asciidoc[]
-
-include::painless-variables.asciidoc[]
-
-include::painless-types.asciidoc[]
-
-include::painless-casting.asciidoc[]
-
-include::painless-operators.asciidoc[]
-
-include::painless-operators-general.asciidoc[]
-
-include::painless-operators-numeric.asciidoc[]
-
-include::painless-operators-boolean.asciidoc[]
-
-include::painless-operators-reference.asciidoc[]
-
-include::painless-operators-array.asciidoc[]
-
-include::painless-statements.asciidoc[]
-
-include::painless-scripts.asciidoc[]
-
-include::painless-functions.asciidoc[]
-
-include::painless-lambdas.asciidoc[]
-
-include::painless-regexes.asciidoc[]
+include::painless-lang-spec/index.asciidoc[]

docs/painless/painless-getting-started.asciidoc renamed to docs/painless/painless-guide/painless-walkthrough.asciidoc

@@ -0,0 +1,35 @@
+include::painless-comments.asciidoc[]
+
+include::painless-keywords.asciidoc[]
+
+include::painless-literals.asciidoc[]
+
+include::painless-identifiers.asciidoc[]
+
+include::painless-variables.asciidoc[]
+
+include::painless-types.asciidoc[]
+
+include::painless-casting.asciidoc[]
+
+include::painless-operators.asciidoc[]
+
+include::painless-operators-general.asciidoc[]
+
+include::painless-operators-numeric.asciidoc[]
+
+include::painless-operators-boolean.asciidoc[]
+
+include::painless-operators-reference.asciidoc[]
+
+include::painless-operators-array.asciidoc[]
+
+include::painless-statements.asciidoc[]
+
+include::painless-scripts.asciidoc[]
+
+include::painless-functions.asciidoc[]
+
+include::painless-lambdas.asciidoc[]
+
+include::painless-regexes.asciidoc[]

docs/painless/painless-lang-spec.asciidoc

@@ -563,7 +563,7 @@ template for all indexes that hold data that needs pre-index processing.
 [[conditionals-with-regex]]
 === Conditionals with the Regular Expressions
 The `if` conditional is implemented as a Painless script, which requires
-{painless}//painless-examples.html#modules-scripting-painless-regex[explicit support for regular expressions].
+{painless}//painless-regexes.html[explicit support for regular expressions].
 
 `script.painless.regex.enabled: true` must be set in `elasticsearch.yml` to use regular
 expressions in the `if` condition.

docs/painless/painless-lang-spec/index.asciidoc

@@ -1,7 +1,32 @@
 [[modules-scripting-painless]]
 === Painless Scripting Language
 
-include::../../../painless/painless-description.asciidoc[]
+_Painless_ is a simple, secure scripting language designed specifically for use
+with Elasticsearch. It is the default scripting language for Elasticsearch and
+can safely be used for inline and stored scripts. To get started with
+Painless, see the {painless}/painless-guide.html[Painless Guide]. For a
+detailed description of the Painless syntax and language features, see the
+{painless}/painless-lang-spec.html[Painless Language Specification].
 
-Ready to start scripting with Painless? See {painless}/painless-getting-started.html[Getting Started with Painless] in the guide to the
+[[painless-features]]
+You can use Painless anywhere scripts can be used in Elasticsearch. Painless
+provides:
+
+* Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
+run several times faster] than the alternatives.
+
+* Safety: Fine-grained whitelist with method call/field granularity. See the
+{painless}/painless-api-reference.html[Painless API Reference] for a
+complete list of available classes and methods.
+
+* Optional typing: Variables and parameters can use explicit types or the
+dynamic `def` type.
+
+* Syntax: Extends a subset of Java's syntax to provide additional scripting
+language features.
+
+* Optimizations: Designed specifically for Elasticsearch scripting.
+
+Ready to start scripting with Painless? See the
+{painless}/painless-guide.html[Painless Guide] for the
 {painless}/index.html[Painless Scripting Language].