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.

chapter-layout.asciidoc 6.1KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130
  1. [[layout]]
  2. == Managing Layout
  3. ////
  4. TODO The intro text below is now completely hidden, as this text is
  5. not visible in web edition and all the text is web-conditional.
  6. ////
  7. ifdef::web[]
  8. Ever since the ancient xeroxians invented graphical user interfaces, programmers
  9. have wanted to make GUI programming ever easier for themselves. Solutions
  10. started simple. When GUIs appeared on PC desktops, practically all screens were
  11. of the VGA type and fixed into 640x480 size. Mac or X Window System on UNIX were
  12. not much different. Everyone was so happy with such awesome graphics resolutions
  13. that they never thought that an application would have to work on a radically
  14. different screen size. At worst, screens could only grow, they thought, giving
  15. more space for more windows. In the 80s, the idea of having a computer screen in
  16. your pocket was simply not realistic. Hence, the GUI APIs allowed placing UI
  17. components using screen coordinates. Visual Basic and some other systems
  18. provided an easy way for the designer to drag and drop components on a
  19. fixed-sized window. One would have thought that at least translators would have
  20. complained about the awkwardness of such a solution, but apparently they were
  21. not, as non-engineers, heard or at least cared about. At best, engineers could
  22. throw at them a resource editor that would allow them to resize the UI
  23. components by hand. Such was the spirit back then.
  24. endif::web[]
  25. ifdef::web[]
  26. After the web was born, layout design was doomed to change for ever. At first,
  27. layout didn't matter much, as everyone was happy with plain headings,
  28. paragraphs, and a few hyperlinks here and there. Designers of HTML wanted the
  29. pages to run on any screen size. The screen size was actually not pixels but
  30. rows and columns of characters, as the baby web was really just hyper __text__,
  31. not graphics. That was soon to be changed. The first GUI-based browser, NCSA
  32. Mosaic, launched a revolution that culminated in Netscape Navigator. Suddenly,
  33. people who had previously been doing advertisement brochures started writing
  34. HTML. This meant that layout design had to be easy not just for programmers, but
  35. also allow the graphics designer to do his or her job without having to know a
  36. thing about programming. The W3C committee designing web standards came up with
  37. the CSS (Cascading Style Sheet) specification, which allowed trivial separation
  38. of appearance from content. Later versions of HTML followed, XHTML and HTML 5
  39. appeared, as did countless other standards.
  40. endif::web[]
  41. ifdef::web[]
  42. Page description and markup languages are a wonderful solution for static
  43. presentations, such as books and most web pages. Real applications, however,
  44. need to have more control. They need to be able to change the state of user
  45. interface components and even their layout on the run. This creates a need to
  46. separate the presentation from content on exactly the right
  47. level.
  48. ////
  49. Vaadin provides a solution for this, using themes and CSS, but let us first look
  50. at what Java did for UI programming.
  51. ////
  52. ////
  53. Changing the layout steps right on the feet of the graphics designers, so we
  54. have a conflict. We will discuss this conflict later, but let us first look at
  55. what Java did for UI programming.
  56. ////
  57. endif::web[]
  58. ifdef::web[]
  59. Thanks to the attack of graphics designers, desktop applications were, when it
  60. comes to appearance, far behind web design. Sun Microsystems had come in 1995
  61. with a new programming language, Java, for writing cross-platform desktop
  62. applications. Java's original graphical user interface toolkit, AWT (Abstract
  63. Windowing Toolkit), was designed to work on multiple operating systems as well
  64. as embedded in web browsers. One of the special aspects of AWT was the layout
  65. manager, which allowed user interface components to be flexible, growing and
  66. shrinking as needed. This made it possible for the user to resize the windows of
  67. an application flexibly and also served the needs of localization, as text
  68. strings were not limited to some fixed size in pixels. It became even possible
  69. to resize the pixel size of fonts, and the rest of the layout adapted to the new
  70. size.
  71. endif::web[]
  72. Layout management of Vaadin is a direct successor of the web-based concept for
  73. separation of content and appearance and of the Java AWT solution for binding
  74. the layout and user interface components into objects in programs. Vaadin layout
  75. components allow you to position your UI components on the screen in a
  76. hierarchical fashion, much like in conventional Java UI toolkits such as AWT,
  77. Swing, or SWT. In addition, you can approach the layout from the direction of
  78. the web with the [classname]#CustomLayout# component, which you can use to write
  79. your layout as a template in HTML that provides locations of any contained
  80. components. The [classname]#AbsoluteLayout# allows the old-style pixel-position
  81. based layouting, but it also supports percentual values, which makes it usable
  82. for scalable layouts. It is also useful as an area on which the user can
  83. position items with drag and drop.
  84. ifdef::web[]
  85. The moral of the story is that, because Vaadin is intended for web applications,
  86. appearance is of high importance. The solutions have to be the best of both
  87. worlds and satisfy artists of both kind: code and graphics. On the API side, the
  88. layout is controlled by UI components, particularly the layout components. On
  89. the visual side, it is controlled by themes. Themes can contain any HTML, Sass,
  90. CSS, and JavaScript that you or your web artists create to make people feel good
  91. about your software.
  92. endif::web[]
  93. include::layout-overview.asciidoc[leveloffset=+2]
  94. include::layout-root-layout.asciidoc[leveloffset=+2]
  95. include::layout-orderedlayout.asciidoc[leveloffset=+2]
  96. include::layout-gridlayout.asciidoc[leveloffset=+2]
  97. include::layout-formlayout.asciidoc[leveloffset=+2]
  98. include::layout-panel.asciidoc[leveloffset=+2]
  99. include::layout-sub-window.asciidoc[leveloffset=+2]
  100. include::layout-splitpanel.asciidoc[leveloffset=+2]
  101. include::layout-tabsheet.asciidoc[leveloffset=+2]
  102. include::layout-accordion.asciidoc[leveloffset=+2]
  103. include::layout-absolutelayout.asciidoc[leveloffset=+2]
  104. include::layout-csslayout.asciidoc[leveloffset=+2]
  105. include::layout-settings.asciidoc[leveloffset=+2]
  106. include::layout-customlayout.asciidoc[leveloffset=+2]