You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

architecture-technology.asciidoc 9.1KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195
  1. ---
  2. title: Technological Background
  3. order: 2
  4. layout: page
  5. ---
  6. [[architecture.technology]]
  7. = Technological Background
  8. ((("Google Web
  9. Toolkit")))
  10. ((("Google Web
  11. Toolkit")))
  12. This section provides an introduction to the various technologies and designs,
  13. which Vaadin Framework is based on. This knowledge is not necessary for using Vaadin Framework, but
  14. provides some background if you need to make low-level extensions to the framework.
  15. [[architecture.technology.html]]
  16. == HTML and JavaScript
  17. ((("HTML")))
  18. ((("JavaScript")))
  19. The World Wide Web, with all its websites and most of the web applications, is
  20. based on the use of the Hypertext Markup Language (HTML). HTML defines the
  21. structure and formatting of web pages, and allows inclusion of graphics and
  22. other resources. It is based on a hierarchy of elements marked with start and
  23. end tags, such as [literal]#++<div> ... </div>++#. Vaadin Framework uses HTML version 5,
  24. although conservatively, to the extent supported by the major browsers, and
  25. their currently most widely used versions.
  26. ((("DOM")))
  27. JavaScript, on the other hand, is a programming language for embedding programs
  28. in HTML pages. JavaScript programs can manipulate a HTML page through the
  29. Document Object Model (DOM) of the page. They can also handle user interaction
  30. events. The Client-Side Engine of the framework and its client-side widgets do exactly
  31. this, although it is actually programmed in Java, which is compiled to
  32. JavaScript with the Vaadin Client Compiler.
  33. Vaadin Framework largely hides the use of HTML, allowing you to concentrate on the UI
  34. component structure and logic. In server-side development, the UI is developed
  35. in Java using UI components and rendered by the client-side engine as HTML, but
  36. it is possible to use HTML templates for defining the layout, as well as HTML
  37. formatting in many text elements. Also when developing client-side widgets and
  38. UIs, the built-in widgets in the framework hide most of HTML DOM manipulation.
  39. [[architecture.technology.styling]]
  40. == Styling with CSS and Sass
  41. ((("CSS")))
  42. ((("Sass")))
  43. While HTML defines the content and structure of a web page, __Cascading Style
  44. Sheet__ (CSS) is a language for defining the visual style, such as colors, text
  45. sizes, and margins. CSS is based on a set of rules that are matched with the
  46. HTML structure by the browser. The properties defined in the rules determine the
  47. visual appearance of the matching HTML elements.
  48. [source, css]
  49. ----
  50. /* Define the color of labels in my view */
  51. .myview .v-label {
  52. color: blue;
  53. }
  54. ----
  55. ((("SCSS")))
  56. ((("CSS3")))
  57. __Sass__, or __Syntactically Awesome Stylesheets__, is an extension of the CSS
  58. language, which allows the use of variables, nesting, and many other syntactic
  59. features that make the use of CSS easier and clearer. Sass has two alternative
  60. formats, SCSS, which is a superset of the syntax of CSS3, and an older indented
  61. syntax, which is more concise. The Vaadin Sass compiler supports the SCSS
  62. syntax.
  63. ((("themes")))
  64. Vaadin Framework handles styling with __themes__ defined with CSS or Sass, and associated
  65. images, fonts, and other resources. Vaadin themes are specifically written in
  66. Sass. In development mode, Sass files are compiled automatically to CSS. For
  67. production use, you compile the Sass files to CSS with the included compiler.
  68. The use of themes is documented in detail in
  69. <<dummy/../../../framework/themes/themes-overview.asciidoc#themes.overview,"Themes">>,
  70. which also gives an introduction to CSS and Sass.
  71. [[architecture.technology.ajax]]
  72. == AJAX
  73. ((("AJAX")))
  74. ((("XML")))
  75. ((("JavaScript")))
  76. ((("HTML
  77. 5")))
  78. ((("CSS")))
  79. ((("DOM")))
  80. ((("XMLHttpRequest")))
  81. AJAX, short for Asynchronous JavaScript and XML, is a technique for developing
  82. web applications with responsive user interaction, similar to traditional
  83. desktop applications. Conventional web applications, be they JavaScript-enabled
  84. or not, can get new page content from the server only by loading an entire new
  85. page. AJAX-enabled pages, on the other hand, handle the user interaction in
  86. JavaScript, send a request to the server asynchronously (without reloading the
  87. page), receive updated content in the response, and modify the page accordingly.
  88. This way, only small parts of the page data need to be loaded. This goal is
  89. archieved by the use of a certain set of technologies: HTML, CSS, DOM,
  90. JavaScript, and the XMLHttpRequest API in JavaScript. XML is just one way to
  91. serialize data between the client and the server, and in Vaadin it is serialized
  92. with the more efficient JSON.
  93. The asynchronous requests used in AJAX are made possible by the
  94. [methodname]#XMLHttpRequest# class in JavaScript. The API feature is available
  95. in all major browsers and is under way to become a W3C standard.
  96. The communication of complex data between the browser and the server requires
  97. some sort of __serialization__ (or __marshalling__) of data objects. The Vaadin
  98. servlet and the client-side engine handle the serialization of shared state
  99. objects from the server-side components to the client-side widgets, as well as
  100. serialization of RPC calls between the widgets and the server-side components.
  101. [[architecture.technology.gwt]]
  102. == GWT
  103. ((("Google Web
  104. Toolkit")))
  105. The client-side of Vaadin Framework is based on GWT.
  106. Its purpose is to make it possible to develop web user interfaces that run in
  107. the browser easily with Java instead of JavaScript. Client-side modules are
  108. developed with Java and compiled into JavaScript with the Vaadin Compiler, which
  109. is an extension of the GWT Compiler. The client-side framework also hides much
  110. of the HTML DOM manipulation and enables handling browser events in Java.
  111. GWT is essentially a client-side technology, normally used to develop user
  112. interface logic in the web browser. Pure client-side modules still need to
  113. communicate with a server using RPC calls and by serializing any data. The
  114. server-driven development mode in the framework effectively hides all the client-server
  115. communications and allows handling user interaction logic in a server-side
  116. application. This makes the architecture of an AJAX-based web application much
  117. simpler. Nevertheless, Vaadin Framework also allows developing pure client-side
  118. applications, as described in
  119. <<dummy/../../../framework/clientsideapp/clientsideapp-overview.asciidoc#clientsideapp.overview,"Client-Side
  120. Applications">>.
  121. See
  122. <<dummy/../../../framework/architecture/architecture-client-side#architecture.client-side,"Client-Side
  123. Engine">> for a description of how the client-side framework based on GWT is
  124. used in the Client-Side Engine of Vaadin Framework.
  125. <<dummy/../../../framework/clientside/clientside-overview.asciidoc#clientside.overview,"Client-Side
  126. Vaadin Development">> provides information about the client-side development,
  127. and
  128. <<dummy/../../../framework/gwt/gwt-overview.asciidoc#gwt.overview,"Integrating
  129. with the Server-Side">> about the integration of client-side widgets with the
  130. server-side components.
  131. [[architecture.technology.servlet]]
  132. == Java Servlets
  133. A Java Servlet is a class that is executed in a Java web server (a __Servlet
  134. container__) to extend the capabilities of the server. In practice, it is
  135. normally a part of a __web application__, which can contain HTML pages to
  136. provide static content, and JavaServer Pages (JSP) and Java Servlets to provide
  137. dynamic content. This is illustrated in
  138. <<figure.architecture.technology.servlet>>.
  139. [[figure.architecture.technology.servlet]]
  140. .Java Web Applications and Servlets
  141. image::img/java-servlet-hi.png[width=80%, scaledwidth=100%]
  142. Web applications are usually packaged and deployed to a server as __WAR__ (
  143. __Web application ARchive__) files, which are Java JAR packages, which in turn
  144. are ZIP compressed packages. The web application is defined in a
  145. deployment descriptor, which defines the servlet
  146. classes and also the mappings from request URL paths to the servlets.
  147. The servlets are Java classes that handle HTTP requests passed to them by the
  148. server through the __Java Servlet API__. They can generate HTML or other content
  149. as a response. JSP pages, on the other hand, are HTML pages, which allow
  150. including Java source code embedded in the pages. They are actually translated
  151. to Java source files by the container and then compiled to servlets.
  152. The UIs of server-side Vaadin applications run as servlets. They are wrapped
  153. inside a [classname]#VaadinServlet# servlet class, which handles session
  154. tracking and other tasks. On the initial request, it returns an HTML loader page
  155. and then mostly JSON responses to synchronize the widgets and their server-side
  156. counterparts. It also serves various resources, such as themes. The server-side
  157. UIs are implemented as classes extending the [classname]#UI# class, as described
  158. in
  159. <<dummy/../../../framework/application/application-overview.asciidoc#application.overview,"Writing
  160. a Server-Side Web Application">>. The class is given as a parameter to the
  161. Vaadin Servlet in the deployment descriptor.
  162. The Client-Side Engine of Vaadin Framework as well as any client-side extension are loaded to the browser as static JavaScript files.
  163. The client-side engine, or widget set in technical terms, needs to be located under the [filename]#VAADIN/widgetsets# path in the web application.
  164. It is normally automatically compiled to include the default widget set, as well as any installed add-ons and custom widgets.