--- title: Technological Background order: 2 layout: page --- [[architecture.technology]] = Technological Background ((("Google Web Toolkit"))) ((("Google Web Toolkit"))) This section provides an introduction to the various technologies and designs, which Vaadin is based on. This knowledge is not necessary for using Vaadin, but provides some background if you need to make low-level extensions to Vaadin. [[architecture.technology.html]] == HTML and JavaScript ((("HTML"))) ((("JavaScript"))) The World Wide Web, with all its websites and most of the web applications, is based on the use of the Hypertext Markup Language (HTML). HTML defines the structure and formatting of web pages, and allows inclusion of graphics and other resources. It is based on a hierarchy of elements marked with start and end tags, such as [literal]#++
...
++#. Vaadin uses HTML version 5, although conservatively, to the extent supported by the major browsers, and their currently most widely used versions. ((("DOM"))) JavaScript, on the other hand, is a programming language for embedding programs in HTML pages. JavaScript programs can manipulate a HTML page through the Document Object Model (DOM) of the page. They can also handle user interaction events. The Client-Side Engine of Vaadin and its client-side widgets do exactly this, although it is actually programmed in Java, which is compiled to JavaScript with the Vaadin Client Compiler. Vaadin largely hides the use of HTML, allowing you to concentrate on the UI component structure and logic. In server-side development, the UI is developed in Java using UI components and rendered by the client-side engine as HTML, but it is possible to use HTML templates for defining the layout, as well as HTML formatting in many text elements. Also when developing client-side widgets and UIs, the built-in widgets in the framework hide most of HTML DOM manipulation. [[architecture.technology.styling]] == Styling with CSS and Sass ((("CSS"))) ((("Sass"))) While HTML defines the content and structure of a web page, __Cascading Style Sheet__ (CSS) is a language for defining the visual style, such as colors, text sizes, and margins. CSS is based on a set of rules that are matched with the HTML structure by the browser. The properties defined in the rules determine the visual appearance of the matching HTML elements. [source, css] ---- /* Define the color of labels in my view */ .myview .v-label { color: blue; } ---- ((("SCSS"))) ((("CSS3"))) __Sass__, or __Syntactically Awesome Stylesheets__, is an extension of the CSS language, which allows the use of variables, nesting, and many other syntactic features that make the use of CSS easier and clearer. Sass has two alternative formats, SCSS, which is a superset of the syntax of CSS3, and an older indented syntax, which is more concise. The Vaadin Sass compiler supports the SCSS syntax. ((("themes"))) Vaadin handles styling with __themes__ defined with CSS or Sass, and associated images, fonts, and other resources. Vaadin themes are specifically written in Sass. In development mode, Sass files are compiled automatically to CSS. For production use, you compile the Sass files to CSS with the included compiler. The use of themes is documented in detail in <>, which also gives an introduction to CSS and Sass. [[architecture.technology.ajax]] == AJAX ((("AJAX"))) ((("XML"))) ((("JavaScript"))) ((("HTML 5"))) ((("CSS"))) ((("DOM"))) ((("XMLHttpRequest"))) AJAX, short for Asynchronous JavaScript and XML, is a technique for developing web applications with responsive user interaction, similar to traditional desktop applications. Conventional web applications, be they JavaScript-enabled or not, can get new page content from the server only by loading an entire new page. AJAX-enabled pages, on the other hand, handle the user interaction in JavaScript, send a request to the server asynchronously (without reloading the page), receive updated content in the response, and modify the page accordingly. This way, only small parts of the page data need to be loaded. This goal is archieved by the use of a certain set of technologies: HTML, CSS, DOM, JavaScript, and the XMLHttpRequest API in JavaScript. XML is just one way to serialize data between the client and the server, and in Vaadin it is serialized with the more efficient JSON. The asynchronous requests used in AJAX are made possible by the [methodname]#XMLHttpRequest# class in JavaScript. The API feature is available in all major browsers and is under way to become a W3C standard. The communication of complex data between the browser and the server requires some sort of __serialization__ (or __marshalling__) of data objects. The Vaadin servlet and the client-side engine handle the serialization of shared state objects from the server-side components to the client-side widgets, as well as serialization of RPC calls between the widgets and the server-side components. [[architecture.technology.gwt]] == Google Web Toolkit ((("Google Web Toolkit"))) The client-side framework of Vaadin is based on the Google Web Toolkit (GWT). Its purpose is to make it possible to develop web user interfaces that run in the browser easily with Java instead of JavaScript. Client-side modules are developed with Java and compiled into JavaScript with the Vaadin Compiler, which is an extension of the GWT Compiler. The client-side framework also hides much of the HTML DOM manipulation and enables handling browser events in Java. GWT is essentially a client-side technology, normally used to develop user interface logic in the web browser. Pure client-side modules still need to communicate with a server using RPC calls and by serializing any data. The server-driven development mode in Vaadin effectively hides all the client-server communications and allows handling user interaction logic in a server-side application. This makes the architecture of an AJAX-based web application much simpler. Nevertheless, Vaadin also allows developing pure client-side applications, as described in <>. See <> for a description of how the client-side framework based on GWT is used in the Client-Side Engine of Vaadin. <> provides information about the client-side development, and <> about the integration of client-side widgets with the server-side components. [[architecture.technology.servlet]] == Java Servlets A Java Servlet is a class that is executed in a Java web server (a __Servlet container__) to extend the capabilities of the server. In practice, it is normally a part of a __web application__, which can contain HTML pages to provide static content, and JavaServer Pages (JSP) and Java Servlets to provide dynamic content. This is illustrated in <>. [[figure.architecture.technology.servlet]] .Java Web Applications and Servlets image::img/java-servlet-hi.png[] Web applications are usually packaged and deployed to a server as __WAR__ ( __Web application ARchive__) files, which are Java JAR packages, which in turn are ZIP compressed packages. The web application is defined in a [filename]#WEB-INF/web.xml# deployment descriptor, which defines the servlet classes and also the mappings from request URL paths to the servlets. This is described in more detail in <>. The class path for the servlets and their dependencies includes the [filename]#WEB-INF/classes# and [filename]#WEB-INF/lib# folders. The [filename]#WEB-INF# is a special hidden folder that can not be accessed by its URL path. The servlets are Java classes that handle HTTP requests passed to them by the server through the __Java Servlet API__. They can generate HTML or other content as a response. JSP pages, on the other hand, are HTML pages, which allow including Java source code embedded in the pages. They are actually translated to Java source files by the container and then compiled to servlets. The UIs of server-side Vaadin applications run as servlets. They are wrapped inside a [classname]#VaadinServlet# servlet class, which handles session tracking and other tasks. On the initial request, it returns an HTML loader page and then mostly JSON responses to synchronize the widgets and their server-side counterparts. It also serves various resources, such as themes. The server-side UIs are implemented as classes extending the [classname]#UI# class, as described in <>. The class is given as a parameter to the Vaadin Servlet in the [filename]#web.xml# deployment descriptor. The Vaadin Client-Side Engine as well as client-side Vaadin applications are loaded to the browser as static JavaScript files. The client-side engine, or widget set in technical terms, needs to be located under the [filename]#VAADIN/widgetsets# path in the web application. The precompiled default widget set is served from the [filename]#vaadin-client-compiled# JAR by the Vaadin Servlet.