docs: fix typos and trailing whitespaces

articles/building-apps/forms-data/add-form/validation/flow.adoc

@@ -67,7 +67,7 @@ Vaadin provides a set of *built-in validators* for common validation scenarios:
 
 * *Numeric Range Validators* -- Ensure that a numeric value falls within a valid range.
   - `BigDecimalRangeValidator`, `BigIntegerRangeValidator`, `ByteRangeValidator`, `DoubleRangeValidator`, `FloatRangeValidator`, `IntegerRangeValidator`, `LongRangeValidator`, `ShortRangeValidator`
-  
+
 * *Date Validators* -- Ensure that a date or time value falls within a valid range.
   - `DateRangeValidator`, `DateTimeRangeValidator`
 
@@ -114,7 +114,7 @@ binder.forField(myNumberField)
 
 === Converters
 
-If you're using value objects or domain primitives in your FDO, you can create a converter by implementing [interfacename]`Converter<T>`. The following example converts between an [clasname]`EmailAddress` and a [classname]`String`:
+If you're using value objects or domain primitives in your FDO, you can create a converter by implementing [interfacename]`Converter<T>`. The following example converts between an [classname]`EmailAddress` and a [classname]`String`:
 
 .EmailAddressConverter.java
 [source,java]
@@ -134,7 +134,7 @@ public class EmailAddressConverter implements Converter<String, EmailAddress> {
     }
 
     @Override
-    public String convertToPresentation(EmailAddress emailAddress, 
+    public String convertToPresentation(EmailAddress emailAddress,
                                         ValueContext context) {
         return emailAddress == null ? null : emailAddress.toString();
     }
@@ -158,7 +158,7 @@ You can add validators after the converter as well. For example, if you need to
 ----
 binder.forField(myEmailAddress)
       .withConverter(new EmailAddressConverter())
-      .withValidator(emailValidationService::notAlreadyInUse, 
+      .withValidator(emailValidationService::notAlreadyInUse,
           "The email address is already in use")
       .bind(myBean::getEmail, myBean::setEmail);
 ----
@@ -205,7 +205,7 @@ The following example ensures that the start date is not after the end date:
 [source,java]
 ----
 binder.withValidator((bean, valueContext) -> {
-    if (bean.getStartDate() != null && bean.getEndDate() != null 
+    if (bean.getStartDate() != null && bean.getEndDate() != null
             && bean.getStartDate().isAfter(bean.getEndDate())) {
         return ValidationResult.error("Start date cannot be after end date");
     }
@@ -257,4 +257,4 @@ This ensures that validation messages are displayed appropriately, whenever they
 
 //== Try It
 
-//- TODO Write a tutorial here
+//- TODO Write a tutorial here

articles/building-apps/forms-data/consistency/transactions/declarative.adoc

@@ -68,7 +68,7 @@ public class MyApplicationService {
     @Transactional
     public void myMethod(MyInput input) {
         if (!isValid(input)) {
-            throw new IllegalArgumentExcpetion("Bad input");
+            throw new IllegalArgumentException("Bad input");
         }
         ...
     }
@@ -116,7 +116,7 @@ public class MyApplicationService {
 
 == Caveats
 
-When working with declarative transactions, it's important to remember that the annotations themselves don't manage any transactions. They're merely instructions for how Spring should manage the transactions. 
+When working with declarative transactions, it's important to remember that the annotations themselves don't manage any transactions. They're merely instructions for how Spring should manage the transactions.
 
 During application startup, Spring detects the `@Transactional` annotation and turns the service into a proxy. When a client calls the proxy, the call is routed through a _method interceptor_. The interceptor starts the transaction, calls the actual method, and then commits the transaction when the method returns, as illustrated in this diagram:
 
@@ -141,12 +141,12 @@ public class MyApplicationService {
     public void mySecondMethod() {
         // myFirstMethod() will participate in the transaction of mySecondMethod(),
         // even though it has been annotated as REQUIRES_NEW.
-        myFirstMethod(); 
+        myFirstMethod();
     }
 }
 ----
 
 You can fix this by managing the transactions, <<programmatic#,programmatically>>.
 
-// Actually, you can fix it by using AspectJ proxies as well, but I don't want to go there. 
- 
+// Actually, you can fix it by using AspectJ proxies as well, but I don't want to go there.
+

articles/building-apps/security/add-login/flow.adoc

@@ -323,7 +323,7 @@ public class TaskListView extends Main {
 ----
 
 [NOTE]
-[annotationame]`@PermitAll` allows _all authenticated users_ to access the view.
+[annotationname]`@PermitAll` allows _all authenticated users_ to access the view.
 
 ====
 

articles/building-apps/security/protect-views/flow.adoc

@@ -24,7 +24,7 @@ The easiest way to grant or deny access to a Flow view is to use annotations. Th
 [NOTE]
 The `@AnonymousAllowed` annotation is a Vaadin-specific annotation; the others are Jakarta annotations (JSR-250). The Spring Security annotations `@Secured` and `@PreAuthorize` are *not supported on views*.
 
-The following example uses [annoationname]`@AnonymousAllowed` to allow *all users* -- both authenticated and unauthenticated -- to access the view:
+The following example uses [annotationname]`@AnonymousAllowed` to allow *all users* -- both authenticated and unauthenticated -- to access the view:
 
 [source,java]
 ----

articles/components/upload/file-handling.adoc

@@ -16,7 +16,7 @@ The uploading of files may be handled either with Vaadin Flow using Java, or wit
 
 The Java Flow Upload component provides an API to handle directly uploaded file data, without having to set up an endpoint or a servlet. It uses an [classname]`UploadHandler` implementation to handle the incoming file data.
 
-[classname]`UploadHandler` is a functional interface that only requires the [methodame]`handleUploadRequest(UploadEvent)` to be implemented for receiving data or use one of the built-in implementations.
+[classname]`UploadHandler` is a functional interface that only requires the [methodname]`handleUploadRequest(UploadEvent)` to be implemented for receiving data or use one of the built-in implementations.
 
 The following built-in implementations of [classname]`UploadHandler` are available:
 

articles/designing-apps/color.adoc

@@ -27,7 +27,7 @@ Should you need help generating a color palette, there are many tools available
 Lumo's <</styling/lumo/lumo-style-properties/color#,color palette>> consists of grayscale shades, blue as the primary color, red for errors, green for success, yellow for warnings, and text colors:
 
 .Lumo's Color Palette
-image::images/color-palette.png[A grid of colors, with a color scale for grayscale, blue, red, greend, and yellow.]
+image::images/color-palette.png[A grid of colors, with a color scale for grayscale, blue, red, green, and yellow.]
 
 Follow the “less is more” approach when using color in your application. Limiting your color palette to a few strategic choices -- such as one primary color, a couple of accent shades, and neutral tones -- helps to create a clean, cohesive interface. This reduces visual clutter and ensures that important elements stand out. Keep it simple for a more intuitive and focused user experience.
 

articles/flow/advanced/signals.adoc

@@ -239,16 +239,16 @@ public class PersonList extends VerticalLayout {
     private final ListSignal<String> persons =
             SignalFactory.IN_MEMORY_SHARED.list("persons", String.class);
 
-    public PersonList() {      
+    public PersonList() {
         Button addButton = new Button("Add Person", click -> {
             persons.insertFirst("New person");
         });
-        
+
         Button updateButton = new Button("Update first Person", click -> {
             ValueSignal<String> first = persons.value().get(0);
             first.update(text -> text + " updated");
         });
-        
+
         UnorderedList list = new UnorderedList();
         ComponentEffect.effect(list, () -> {
             list.removeAll();
@@ -264,7 +264,7 @@ public class PersonList extends VerticalLayout {
 }
 ----
 
-Removing all list items and creating them again is not the most efficent soltuion. A helper method will be added later to bind child components in a more efficient way.
+Removing all list items and creating them again is not the most efficient solution. A helper method will be added later to bind child components in a more efficient way.
 
 The effect that creates new list item components will be run only when a new item is added to the list but not when the value of an existing item is updated.
 
@@ -343,7 +343,7 @@ If that is not possible and you are certain there's no risk for infinite loops,
 
 [source,java]
 ----
-CompnentEffect.effect(() -> {
+ComponentEffect.effect(() -> {
   String value = oneSignal.value();
 
   // This might lead to infinite loops.

articles/flow/testing/end-to-end/advanced-concepts.adoc

@@ -320,7 +320,7 @@
 ----
 --
 
-Parameterized tests can also run on multiple remote browsers, using a similar setup. The main difference is that the base class should be annotated with [annotionname]`@RunOnHub`, and the subclasses should have a method annotated with [annotationname]`@BrowserConfiguration` that returns a [interfacename]`List` containing a single [classname]`DesiredCapabilities` item. Note that the subclasses must have `public` visibility to work with [annotationname]`@BrowserConfiguration` annotation.
+Parameterized tests can also run on multiple remote browsers, using a similar setup. The main difference is that the base class should be annotated with [annotationname]`@RunOnHub`, and the subclasses should have a method annotated with [annotationname]`@BrowserConfiguration` that returns a [interfacename]`List` containing a single [classname]`DesiredCapabilities` item. Note that the subclasses must have `public` visibility to work with [annotationname]`@BrowserConfiguration` annotation.
 
 [.example]
 --

articles/tools/mpr/configuration/push.adoc

@@ -8,9 +8,9 @@
 
 = Push & MPR
 
-To enable server push for any navigation target in MPR, add the [annotationame]`@Push` Flow annotation on the Flow application shell class. The application shell class is a plain Java class implementing the [interfacename]`AppShellConfigurator` interface.
+To enable server push for any navigation target in MPR, add the [annotationname]`@Push` Flow annotation on the Flow application shell class. The application shell class is a plain Java class implementing the [interfacename]`AppShellConfigurator` interface.
 
-The [annotationame]`@Push` annotation has similar parameters (except for the deprecated ones) as the ones used in the Vaadin 7 and 8.
+The [annotationname]`@Push` annotation has similar parameters (except for the deprecated ones) as the ones used in the Vaadin 7 and 8.
 
 See <<{articles}/flow/advanced/server-push#,Server Push>> for instructions how to configure push in Flow and the `@Push` annotation JavaDoc for descriptions on each parameter.