diff options
Diffstat (limited to 'documentation/advanced')
10 files changed, 33 insertions, 33 deletions
diff --git a/documentation/advanced/advanced-architecture.asciidoc b/documentation/advanced/advanced-architecture.asciidoc index 64b9b78add..a8b61ae616 100644 --- a/documentation/advanced/advanced-architecture.asciidoc +++ b/documentation/advanced/advanced-architecture.asciidoc @@ -9,7 +9,7 @@ layout: page In this section, we continue from the basic application architectures described in -<<dummy/../../../framework/application/application-architecture#application.architecture,"Building +<<../application/application-architecture#application.architecture,"Building the UI">> and discuss some of the more advanced patterns that are often used in Vaadin applications. @@ -29,7 +29,7 @@ model and the "business logic" of the application, typically as beans or POJOs. A user interface is built on top of the domain model, in our context with the Vaadin Framework. The Vaadin user interface could be bound directly to the data model through the Vaadin Data Model, described in -<<dummy/../../../framework/datamodel/datamodel-overview.asciidoc#datamodel.overview,"Binding Components to Data">>. +<<../datamodel/datamodel-overview.asciidoc#datamodel.overview,"Binding Components to Data">>. Beneath the domain model lies a data store, such as a relational database. The dependencies between the layers are restricted so that a higher layer may depend on a lower one, but never the other way around. diff --git a/documentation/advanced/advanced-cdi.asciidoc b/documentation/advanced/advanced-cdi.asciidoc index e3c3b5a679..86c39b88e1 100644 --- a/documentation/advanced/advanced-cdi.asciidoc +++ b/documentation/advanced/advanced-cdi.asciidoc @@ -143,13 +143,13 @@ public class MainView extends CustomComponent implements View { Vaadin CDI requires a Java EE 7 compatible servlet container, such as Glassfish or Apache TomEE Web Profile, as mentioned for the reference toolchain in -<<dummy/../../../framework/getting-started/getting-started-environment#getting-started.environment,"Setting +<<../getting-started/getting-started-environment#getting-started.environment,"Setting up the Development Environment">>. To install the Vaadin CDI add-on, either define it as an Ivy or Maven dependency or download it from the Vaadin Directory add-on page at <<,vaadin.com/directory#addon/vaadin-cdi>>. See -<<dummy/../../../framework/addons/addons-overview.asciidoc#addons.overview,"Using +<<../addons/addons-overview.asciidoc#addons.overview,"Using Vaadin Add-ons">> for general instructions for installing and using Vaadin add-ons. @@ -197,7 +197,7 @@ servlet, see <<advanced.cdi.deployment>>. Vaadin CDI offers an easier way to instantiate UIs and to define the URL mapping for them than the usual ways described in -<<dummy/../../../framework/application/application-environment#application.environment,"Deploying +<<../application/application-environment#application.environment,"Deploying an Application">>. To define a UI class that should be instantiated for a given URL, you simply need to annotate the class with [classname]#@CDIUI#. It takes an optional URL path as parameter. @@ -334,7 +334,7 @@ must be synchronized. The lifecycle and visibility of session-scoped beans is bound to a HTTP or user session, which in Vaadin applications is associated with the [classname]#VaadinSession# (see -<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.session,"User +<<../application/application-lifecycle#application.lifecycle.session,"User Session">>). This is a very typical scope to store user data, as is done in many examples in this section, or database connections. The lifecycle of session-scoped beans starts when a user opens the page for a UI in the browser, @@ -476,7 +476,7 @@ other Vaadin servlets. === Custom Servlets When customizing the Vaadin servlet, as outlined in -<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.servlet-service,"Vaadin +<<../application/application-lifecycle#application.lifecycle.servlet-service,"Vaadin Servlet, Portlet, and Service">>, you simply need to extend [classname]#com.vaadin.cdi.internal.VaadinCDIServlet# instead of [classname]#com.vaadin.servlet.VaadinServlet#. @@ -484,7 +484,7 @@ Servlet, Portlet, and Service">>, you simply need to extend The custom servlet must not have [classname]#@WebServlet# annotation or [classname]#@VaadinServletConfiguration#, as you would normally with a Vaadin servlet, as described in -<<dummy/../../../framework/application/application-environment#application.environment,"Deploying +<<../application/application-environment#application.environment,"Deploying an Application">>. @@ -494,7 +494,7 @@ ifdef::web[] == View Navigation Vaadin CDI extends the navigation framework in Vaadin, described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator,"Navigating +<<../advanced/advanced-navigator#advanced.navigator,"Navigating in an Application">>. It manages CDI views with a special view provider and enables view scoping. @@ -502,7 +502,7 @@ enables view scoping. === Preparing the UI You can define navigation for any single-component container, as described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator.navigating,"Setting +<<advanced-navigator#advanced.navigator.navigating,"Setting Up for Navigation">>, but typically you set up navigation for the entire UI content. To use Vaadin CDI views, you need to inject a [classname]#CDIViewProvider# in the UI and add it as a provider for the @@ -787,7 +787,7 @@ events. CDI events are not propagated to inactive contexts, and only the context of the currently processed UI is active. Further, as explained in -<<dummy/../../../framework/advanced/advanced-push#advanced.push.running,"Accessing +<<advanced-push#advanced.push.running,"Accessing UI from Another Thread">>, other Vaadin UIs may not be accessed without proper synchronization, as their requests are processed concurrently in different server threads. Therefore, you need to pass the events through an @@ -795,7 +795,7 @@ application-scoped messaging service and synchronize the access to other UIs by using the [methodname]#access()# method. In -<<dummy/../../../framework/advanced/advanced-push#advanced.push.pusharound,"Broadcasting +<<advanced-push#advanced.push.pusharound,"Broadcasting to Other Users">> we looked into how to pass messages to all other UIs using a broadcasting service. In that example, we used static variables and methods to store references and to access the service. With CDI, we can let the context diff --git a/documentation/advanced/advanced-debug.asciidoc b/documentation/advanced/advanced-debug.asciidoc index 3ff5a55ab4..40f3d16cb9 100644 --- a/documentation/advanced/advanced-debug.asciidoc +++ b/documentation/advanced/advanced-debug.asciidoc @@ -121,7 +121,7 @@ debugging the component tree in various ways. The [guibutton]#Show the connector hierarchy tree# button displays the client-side connector hierarchy. As explained in -<<dummy/../../../framework/gwt/gwt-overview.asciidoc#gwt.overview,"Integrating +<<../gwt/gwt-overview.asciidoc#gwt.overview,"Integrating with the Server-Side">>, client-side widgets are managed by connectors that handle communication with the server-side component counterparts. The connector hierarchy therefore corresponds with the server-side component tree, but the @@ -204,5 +204,5 @@ get more detailed information about the requests and responses. The [guilabel]#Menu# tab in the window opens a sub-menu to select various settings. Here you can also launch the GWT SuperDevMode, as described in -<<dummy/../../../framework/clientside/clientside-debugging#clientside.debugging,"Debugging +<<../clientside/clientside-debugging#clientside.debugging,"Debugging Client-Side Code">>. diff --git a/documentation/advanced/advanced-embedding.asciidoc b/documentation/advanced/advanced-embedding.asciidoc index 8aa294f4e5..868fac9569 100644 --- a/documentation/advanced/advanced-embedding.asciidoc +++ b/documentation/advanced/advanced-embedding.asciidoc @@ -167,8 +167,8 @@ future.+ [parameter]#theme#:: Name of the theme, such as one of the built-in themes ( [literal]#++reindeer++#, [literal]#++runo++#, or [literal]#++chameleon++#) or a custom theme. It must exist under the [filename]#VAADIN/themes# folder. [parameter]#versionInfo#:: This parameter is itself an associative map that can contain two parameters: [parameter]#vaadinVersion# contains the version number of the Vaadin version used by the application. The [parameter]#applicationVersion# parameter contains the version of the particular application. The contained parameters are optional, but the [parameter]#versionInfo# parameter itself is not. [parameter]#vaadinDir#:: Relative path to the [filename]#VAADIN# directory. It is relative to the URL of the embedding page. -[parameter]#heartbeatInterval#:: The [parameter]#hearbeatInterval# parameter defines the frequency of the keep-alive hearbeat for the UI in seconds, as described in <<dummy/../../../framework/application/application-lifecycle#application.lifecycle.ui-expiration,"UI Expiration">>. -[parameter]#debug#:: The parameter defines whether the debug window, as described in <<dummy/../../../framework/advanced/advanced-debug#advanced.debug,"Debug Mode and Window">>, is enabled. +[parameter]#heartbeatInterval#:: The [parameter]#hearbeatInterval# parameter defines the frequency of the keep-alive hearbeat for the UI in seconds, as described in <<../application/application-lifecycle#application.lifecycle.ui-expiration,"UI Expiration">>. +[parameter]#debug#:: The parameter defines whether the debug window, as described in <<../advanced/advanced-debug#advanced.debug,"Debug Mode and Window">>, is enabled. [parameter]#standalone#:: This parameter should be [parameter]#false# when embedding. The parameter defines whether the UI is rendered on its own in the browser window or in some context. A standalone UI may do things that might interfere with other parts of the page, such as change the page title and request focus when it is loaded. When embedding, the UI is not standalone. [parameter]#authErrMsg#,[parameter]#comErrMsg#, and[parameter]#sessExpMsg#:: These three parameters define the client-side error messages for authentication error, communication error, and session expiration, respectively. The parameters are associative maps themselves and must contain two key-value pairs: [parameter]#message#, which should contain the error text in HTML, and [parameter]#caption#, which should be the error caption. @@ -204,7 +204,7 @@ For example: ---- Notice that many of the parameters are normally deployment parameters, specified in the deployment descriptor, as described in -<<dummy/../../../framework/application/application-environment#application.environment.parameters,"Other +<<../application/application-environment#application.environment.parameters,"Other Servlet Configuration Parameters">>. endif::web[] diff --git a/documentation/advanced/advanced-javascript.asciidoc b/documentation/advanced/advanced-javascript.asciidoc index 055d2e288f..f9c90e8a61 100644 --- a/documentation/advanced/advanced-javascript.asciidoc +++ b/documentation/advanced/advanced-javascript.asciidoc @@ -101,7 +101,7 @@ Link link = new Link("Send Message", new ExternalResource( The function callback mechanism is the same as the RPC mechanism used with JavaScript component integration, as described in -<<dummy/../../../framework/gwt/gwt-javascript#gwt.javascript.rpc,"RPC from +<<../gwt/gwt-javascript#gwt.javascript.rpc,"RPC from JavaScript to Server-Side">>. diff --git a/documentation/advanced/advanced-pushstate.asciidoc b/documentation/advanced/advanced-pushstate.asciidoc index 5797366dec..f5a991a3ee 100644 --- a/documentation/advanced/advanced-pushstate.asciidoc +++ b/documentation/advanced/advanced-pushstate.asciidoc @@ -20,7 +20,7 @@ methods and a mechanism to listen to changes in the client side URI in the Vaadin offers two ways to modify URIs: the high-level [classname]#Navigator# utility described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator,"Navigating +<<advanced-navigator#advanced.navigator,"Navigating in an Application">> and the low-level API described here. [[advanced.urifu.setting]] diff --git a/documentation/advanced/advanced-requesthandler.asciidoc b/documentation/advanced/advanced-requesthandler.asciidoc index df991bc5cd..09e35710be 100644 --- a/documentation/advanced/advanced-requesthandler.asciidoc +++ b/documentation/advanced/advanced-requesthandler.asciidoc @@ -10,7 +10,7 @@ layout: page Request handlers are useful for catching request parameters or generating dynamic content, such as HTML, images, PDF, or other content. You can provide HTTP content also with stream resources, as described in -<<dummy/../../../framework/application/application-resources#application.resources.stream,"Stream +<<../application/application-resources#application.resources.stream,"Stream Resources">>. The stream resources, however, are only usable from within a Vaadin application, such as in an [classname]#Image# component. Request handlers allow responding to HTTP requests made with the application URL, including GET diff --git a/documentation/advanced/advanced-spring.asciidoc b/documentation/advanced/advanced-spring.asciidoc index ec38db7830..54e0f895c1 100644 --- a/documentation/advanced/advanced-spring.asciidoc +++ b/documentation/advanced/advanced-spring.asciidoc @@ -193,7 +193,7 @@ To install the Vaadin Spring and/or Vaadin Spring Boot add-ons, either define them as an Ivy or Maven dependency or download from the Vaadin Directory add-on page at link:https://vaadin.com/directory#addon/vaadin-spring[vaadin.com/directory#addon/vaadin-spring] or link:https://vaadin.com/directory#addon/vaadin-spring-boot[vaadin.com/directory#addon/vaadin-spring-boot]. -See <<dummy/../../../framework/addons/addons-overview.asciidoc#addons.overview,"Using +See <<../addons/addons-overview.asciidoc#addons.overview,"Using Vaadin Add-ons">> for general instructions for installing and using Vaadin add-ons. @@ -265,7 +265,7 @@ section. Vaadin Spring offers an easier way to instantiate UIs and to define the URL mapping for them than the usual ways described in -<<dummy/../../../framework/application/application-environment#application.environment,"Deploying +<<../application/application-environment#application.environment,"Deploying an Application">>. It is also needed for enabling Spring features in the UI. To define a UI class that should be instantiated for a given URL, you simply need to annotate the class with [classname]#@SpringUI#. It takes an optional path as @@ -371,7 +371,7 @@ ifdef::web[] == View Navigation Vaadin Spring extends the navigation framework in Vaadin, described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator,"Navigating +<<advanced-navigator#advanced.navigator,"Navigating in an Application">>. It manages Spring views with a special view provider and enables view scoping. Furthermore, Vaadin Spring provides a customized navigator class [classname]#SpringNavigator# that supports the scope functionality. @@ -382,7 +382,7 @@ enables view scoping. Furthermore, Vaadin Spring provides a customized navigator You can define navigation for any single-component container, component container or bean implementing [classname]#ViewDisplay#, as described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator.navigating,"Setting +<<advanced-navigator#advanced.navigator.navigating,"Setting Up for Navigation">>, but typically you set up navigation for the entire UI content. The easiest way to set up navigation is to use the annotation [classname]#@SpringViewDisplay# on the UI (in which case the whole contents of the UI are @@ -579,7 +579,7 @@ use Spring with non-Spring servlets and UIs in a web application. === Custom Servlets When customizing the Vaadin servlet, as outlined in -<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.servlet-service,"Vaadin +<<../application/application-lifecycle#application.lifecycle.servlet-service,"Vaadin Servlet, Portlet, and Service">>, you simply need to extend [classname]#com.vaadin.spring.server.SpringVaadinServlet# instead of [classname]#com.vaadin.servlet.VaadinServlet#. @@ -592,7 +592,7 @@ public class [replaceable]#MySpringServlet# extends SpringVaadinServlet { ---- The custom servlet must not have [classname]#@VaadinServletConfiguration#, as you would normally with a Vaadin servlet, as described in -<<dummy/../../../framework/application/application-environment#application.environment,"Deploying +<<../application/application-environment#application.environment,"Deploying an Application">>. diff --git a/documentation/advanced/advanced-urifu.asciidoc b/documentation/advanced/advanced-urifu.asciidoc index e3b6b5c1ba..0792daeb7b 100644 --- a/documentation/advanced/advanced-urifu.asciidoc +++ b/documentation/advanced/advanced-urifu.asciidoc @@ -8,7 +8,7 @@ layout: page = Managing URI Fragments NOTE: This chapter contains instructions how to manage URI fragments. As browser support for HTML5 History API has improved, developers should in most cases developers instead use real URIs with _pushState_ method. Read more from -<<dummy/../../../framework/advanced/advanced-navigator#advanced.pushstate,"Manipulating Browser History">>. +<<advanced-navigator#advanced.pushstate,"Manipulating Browser History">>. A major issue in AJAX applications is that as they run in a single web page, bookmarking the application URL (or more generally the __URI__) can only @@ -33,7 +33,7 @@ the slash and the question mark. Vaadin offers two ways to enable the use of URI fragments: the high-level [classname]#Navigator# utility described in -<<dummy/../../../framework/advanced/advanced-navigator#advanced.navigator,"Navigating +<<advanced-navigator#advanced.navigator,"Navigating in an Application">> (if the legacy [classname]#UriFragmentManager# is configured for the Navigator) and the low-level API described here. [[advanced.urifu.setting]] @@ -183,7 +183,7 @@ avoid having the [literal]#++_escaped_fragment_++# parameter. You need to use the custom servlet class in the [filename]#web.xml# deployment descriptor instead of the normal [classname]#VaadinServlet# class, as described in -<<dummy/../../../framework/application/application-environment#application.environment.web-xml,"Using +<<../application/application-environment#application.environment.web-xml,"Using a web.xml Deployment Descriptor">>. diff --git a/documentation/advanced/advanced-windows.asciidoc b/documentation/advanced/advanced-windows.asciidoc index 60245dc910..dc12deadc3 100644 --- a/documentation/advanced/advanced-windows.asciidoc +++ b/documentation/advanced/advanced-windows.asciidoc @@ -14,23 +14,23 @@ tabs, either opened by the user using an URL or by the Vaadin application. In addition to native browser windows, Vaadin has a [classname]#Window# component, which is a floating panel or __sub-window__ inside a page, as described in -<<dummy/../../../framework/layout/layout-sub-window#layout.sub-window,"Sub-Windows">>. +<<../layout/layout-sub-window#layout.sub-window,"Sub-Windows">>. * __Native popup windows__. An application can open popup windows for sub-tasks. * __Page-based browsing__. The application can allow the user to open certain content to different windows. For example, in a messaging application, it can be useful to open different messages to different windows so that the user can browse through them while writing a new message. * __Bookmarking__. Bookmarks in the web browser can provide an entry-point to some content provided by an application. -* __Embedding UIs__. UIs can be embedded in web pages, thus making it possible to provide different views to an application from different pages or even from the same page, while keeping the same session. See <<dummy/../../../framework/advanced/advanced-embedding#advanced.embedding,"Embedding UIs in Web Pages">>. +* __Embedding UIs__. UIs can be embedded in web pages, thus making it possible to provide different views to an application from different pages or even from the same page, while keeping the same session. See <<advanced-embedding#advanced.embedding,"Embedding UIs in Web Pages">>. Use of multiple windows in an application may require defining and providing different UIs for the different windows. The UIs of an application share the same user session, that is, the [classname]#VaadinSession# object, as described in -<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.session,"User +<<../application/application-lifecycle#application.lifecycle.session,"User Session">>. Each UI is identified by a URL that is used to access it, which makes it possible to bookmark application UIs. UI instances can even be created dynamically based on the URLs or other request parameters, such as browser information, as described in -<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.ui,"Loading +<<../application/application-lifecycle#application.lifecycle.ui,"Loading a UI">>. Because of the special nature of AJAX applications, use of multiple windows uses |