From 36aabcc34ef4193739bcfab6f8b5516eda128178 Mon Sep 17 00:00:00 2001 From: web-padawan Date: Wed, 19 Nov 2025 11:45:21 +0200 Subject: [PATCH] docs: fix typos and trailing whitespaces --- .../forms-data/add-form/validation/flow.adoc | 12 ++++++------ .../consistency/transactions/declarative.adoc | 10 +++++----- articles/building-apps/security/add-login/flow.adoc | 2 +- .../building-apps/security/protect-views/flow.adoc | 2 +- articles/components/upload/file-handling.adoc | 2 +- articles/designing-apps/color.adoc | 2 +- articles/flow/advanced/signals.adoc | 10 +++++----- .../flow/testing/end-to-end/advanced-concepts.adoc | 2 +- articles/tools/mpr/configuration/push.adoc | 4 ++-- 9 files changed, 23 insertions(+), 23 deletions(-) diff --git a/articles/building-apps/forms-data/add-form/validation/flow.adoc b/articles/building-apps/forms-data/add-form/validation/flow.adoc index 6c10c66545..ee30b16edd 100644 --- a/articles/building-apps/forms-data/add-form/validation/flow.adoc +++ b/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`. 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`. 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 { } @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 \ No newline at end of file +//- TODO Write a tutorial here diff --git a/articles/building-apps/forms-data/consistency/transactions/declarative.adoc b/articles/building-apps/forms-data/consistency/transactions/declarative.adoc index d881d579dd..bc121f3052 100644 --- a/articles/building-apps/forms-data/consistency/transactions/declarative.adoc +++ b/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, <>. -// 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. + diff --git a/articles/building-apps/security/add-login/flow.adoc b/articles/building-apps/security/add-login/flow.adoc index 6849f575ca..4f1df88845 100644 --- a/articles/building-apps/security/add-login/flow.adoc +++ b/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. ==== diff --git a/articles/building-apps/security/protect-views/flow.adoc b/articles/building-apps/security/protect-views/flow.adoc index f9bb6ee0eb..31a5f5a98f 100644 --- a/articles/building-apps/security/protect-views/flow.adoc +++ b/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] ---- diff --git a/articles/components/upload/file-handling.adoc b/articles/components/upload/file-handling.adoc index e8edc36250..1aa4dfeb97 100644 --- a/articles/components/upload/file-handling.adoc +++ b/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: diff --git a/articles/designing-apps/color.adoc b/articles/designing-apps/color.adoc index b4dd0bc451..3585db440a 100644 --- a/articles/designing-apps/color.adoc +++ b/articles/designing-apps/color.adoc @@ -27,7 +27,7 @@ Should you need help generating a color palette, there are many tools available Lumo's <> 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. diff --git a/articles/flow/advanced/signals.adoc b/articles/flow/advanced/signals.adoc index 6e4bddaf0e..5907381472 100644 --- a/articles/flow/advanced/signals.adoc +++ b/articles/flow/advanced/signals.adoc @@ -239,16 +239,16 @@ public class PersonList extends VerticalLayout { private final ListSignal 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 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. diff --git a/articles/flow/testing/end-to-end/advanced-concepts.adoc b/articles/flow/testing/end-to-end/advanced-concepts.adoc index c67b5fcef3..b23211c373 100644 --- a/articles/flow/testing/end-to-end/advanced-concepts.adoc +++ b/articles/flow/testing/end-to-end/advanced-concepts.adoc @@ -320,7 +320,7 @@ class FirefoxParameterizedIT extends AbstractParameterizedTest { ---- -- -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] -- diff --git a/articles/tools/mpr/configuration/push.adoc b/articles/tools/mpr/configuration/push.adoc index 0af402bfe3..fedcb19d68 100644 --- a/articles/tools/mpr/configuration/push.adoc +++ b/articles/tools/mpr/configuration/push.adoc @@ -8,9 +8,9 @@ order: 3 = 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.