From 5bbc31f2adac00c3284b0a9d992551c754eb8274 Mon Sep 17 00:00:00 2001 From: Veera Paananen Date: Thu, 19 Dec 2024 10:07:39 +0000 Subject: [PATCH] Remove links pointing to Hilla documentation (latest version) for now --- articles/advanced/modifying-the-bootstrap-page.asciidoc | 2 +- articles/configuration/pwa.asciidoc | 2 +- articles/security/enabling-security.adoc | 2 +- articles/upgrading/recommended-changes/index.adoc | 2 +- articles/upgrading/upgrade-tool/flow/_14-15.adoc | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/articles/advanced/modifying-the-bootstrap-page.asciidoc b/articles/advanced/modifying-the-bootstrap-page.asciidoc index 3778324896..2b471a26fa 100644 --- a/articles/advanced/modifying-the-bootstrap-page.asciidoc +++ b/articles/advanced/modifying-the-bootstrap-page.asciidoc @@ -86,7 +86,7 @@ const {serverSideRoutes} = new Flow({ }); const routes = [ - // for client-side, place routes below (more info https://vaadin.com/docs/latest/hilla/guides/routing) + // for client-side, place routes below // for server-side, the next magic line sends all unmatched routes: ...serverSideRoutes // IMPORTANT: this must be the last entry in the array diff --git a/articles/configuration/pwa.asciidoc b/articles/configuration/pwa.asciidoc index f400e73256..cc92084830 100644 --- a/articles/configuration/pwa.asciidoc +++ b/articles/configuration/pwa.asciidoc @@ -12,7 +12,7 @@ They look like a regular application in the home screen of a mobile device or in A PWA needs some metadata, such as name, description, and icon, which are used by the operating system to display information about the application. To enable offline use, TypeScript needs to be used to provide the offline views. -https://vaadin.com/hilla[Hilla] is the recommended framework to build client-side views. +Hilla is the recommended framework to build client-side views. For a generic introduction to PWA, see the article on https://vaadin.com/pwa[What are Progressive Web Applications and Why Build a PWA]. diff --git a/articles/security/enabling-security.adoc b/articles/security/enabling-security.adoc index 44cfcd967b..42d2809767 100644 --- a/articles/security/enabling-security.adoc +++ b/articles/security/enabling-security.adoc @@ -293,7 +293,7 @@ The most important configuration in the above example is the call to [methodname This is how the view-based access control mechanism knows where to redirect users when they try to navigate to a protected view. The log-in view should always be accessible by anonymous users, so it should have the [annotationname]`@AnonymousAllowed` annotation. -This is especially important when using the variant of the [methodname]`setLoginView` method where you provide the route path (although this signature is meant to be used with https://vaadin.com/hilla[Hilla] views, not with Flow views). +This is especially important when using the variant of the [methodname]`setLoginView` method where you provide the route path (although this signature is meant to be used with Hilla views, not with Flow views). .Component-based security configuration diff --git a/articles/upgrading/recommended-changes/index.adoc b/articles/upgrading/recommended-changes/index.adoc index 367c0d55c8..beb5b0df61 100644 --- a/articles/upgrading/recommended-changes/index.adoc +++ b/articles/upgrading/recommended-changes/index.adoc @@ -29,7 +29,7 @@ The reason for this API change is that, with client-side bootstrapping, the init - In Vaadin 10 to 14, these two steps are combined and the [filename]`index.html` page includes the code and configuration needed to start the Flow client engine and link the browser page to the server-side [classname]`UI` instance. - In Vaadin 15 and later, with client-side bootstrapping, the [filename]`index.html` page includes only the basic HTML markup and links to the TypeScript UI code. -If you have https://vaadin.com/docs/latest/hilla/guides/routing[client-side/Hilla views], the [classname]`UI` isn't guaranteed to be created, and so it's optional. +If you have Hilla views, the [classname]`UI` isn't guaranteed to be created, and so it's optional. It's available only after the user navigates to a server-side route. It's also possible to continue using the bootstrapping mode in V10-14 with the `useDeprecatedV14Bootstrapping` flag. diff --git a/articles/upgrading/upgrade-tool/flow/_14-15.adoc b/articles/upgrading/upgrade-tool/flow/_14-15.adoc index e443f3bc61..87579c1938 100644 --- a/articles/upgrading/upgrade-tool/flow/_14-15.adoc +++ b/articles/upgrading/upgrade-tool/flow/_14-15.adoc @@ -43,7 +43,7 @@ The reason for this API change is that with client-side bootstrapping the initia - In Vaadin 10 to 14 these two steps are combined and the `index.html` page includes the code and configuration needed to start the Flow client engine and link the browser page to the server-side `UI` instance. -- In Vaadin 15+ with client-side bootstrapping the `index.html` page includes only the basic HTML markup and links to the TypeScript UI code. If you have https://vaadin.com/docs/latest/hilla/guides/routing[client-side/Hilla views], the `UI` isn't guaranteed to be created, thus is optional. It's only available after the user navigates to a server-side route. +- In Vaadin 15+ with client-side bootstrapping the `index.html` page includes only the basic HTML markup and links to the TypeScript UI code. If you have Hilla views, the `UI` isn't guaranteed to be created, thus is optional. It's only available after the user navigates to a server-side route. It's also possible to continue using the bootstrapping mode in V10-14 with the `useDeprecatedV14Bootstrapping` flag. See how the use the flag in <<{articles}/configuration/properties#, Configuration Properties>>.