Tipi - Building Rich User Interfaces


Published on

Tipi allows developers to quickly create rich user interfaces build on top of a SOA. Tipi is easy to learn, flexible and open source.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Tipi - Building Rich User Interfaces

  1. 1. 1 donderdag 9 juli 2009
  2. 2. OVERVIEW » introducing tipi 1. Introducing Tipi 2. Tipi XML Basics 3. Working with Tipi 4. Managing a Tipi project 5. Extending Tipi 6. Customizing appearance 7. How it all ties up 2 donderdag 9 juli 2009
  3. 3. 1. INTRODUCING TIPI » about tipi About Tipi — Building applications with Tipi Tipi fundamentals — what are the main building blocks of a Tipi application? 3 donderdag 9 juli 2009
  4. 4. ABOUT TIPI » tipi fundamentals Tipi — a universal user interface layer used for defining user interfaces Easy to learn XML-based language Separates form and representation: Tipi defines how a UI is structured and how you can click through it, not what it actually looks like Built on top of a data abstraction layer which we commonly call Navajo services 4 donderdag 9 juli 2009
  5. 5. TIPI FUNDAMENTALS » ui elements UI elements — a user interface is built up of different type of elements such as windows, panels, menus etc. UI logic — the flow through a user interface defines how elements interact with each other and with the data they represent Navajo data structure — a dedicated UI language needs an elegant way of retrieving and incorporating data. Where applicable, business rules should be implemented on the service layer and not in the user interface 5 donderdag 9 juli 2009
  6. 6. UI ELEMENTS » ui logic UI elements are the building blocks of an application. They define what the user sees; what he or she can click on When thinking of UI elements, think windows, panels, menus, buttons, tables, text fields, labels, sliders, toolbars, dialogs, images, tabs, … 6 donderdag 9 juli 2009
  7. 7. UI LOGIC » actions UI logic represents the flow through an application. Typically users can click on things, after which things happen, screens are opened, data is loaded, the user is given some feedback, … Implementation of UI logic breaks down in actions, events and event listeners Actions do stuff — e.g. instantiate a window Events are fired — e.g. a value is changed, a mouse is clicked, a window opened Event Listeners — can be defined to actually trigger when certain events occur. E.g.: onLoad, onInstantiate, … 7 donderdag 9 juli 2009
  8. 8. ACTIONS » events Actions can manipulate data, fire user interface events, display messages, … Different types of UI elements support different types of actions: e.g. dialogs can be opened, questions answered, tables browsed, etc. Actions are placed within event listeners, to define what should happen when a certain event occurs 8 donderdag 9 juli 2009
  9. 9. EVENTS » event listeners Different types of UI elements support different types of events, although some share common ones In order to actually do something with an event, an event listener must be defined, that specifies what subsequent actions you want the application to perform 9 donderdag 9 juli 2009
  10. 10. EVENT LISTENERS » navajo data structure Event listeners break down into two main categories: UI elements support specific events which in most cases have event listeners associated with them. E.g. buttons have an onActionPerformed, windows an onInstantiate, and dropdowns a onSelectionChanged In addition, data elements such as properties and tables listen to incoming Navajo services. This is what we call service listeners 10 donderdag 9 juli 2009
  11. 11. NAVAJO DATA STRUCTURE » combined data and metadata Tipi expects its data to be supplied by Navajo services in an XTML format XTML is a single schema XML format, meant for easy reading and writing XTML consists of a collection of messages and properties that structure data XTML combines data & metadata, which means that a certain level of semantics is added to the data Navajo services are commonly broken down in granularity to serve specific information needs 11 donderdag 9 juli 2009
  12. 12. COMBINED DATA & METADATA » tipi xml basics By including basic types in properties—e.g. whether they are strings, numbers, dates, money fields etc.—the Navajo service layer can: supply hints to the UI layer of how to represent the data make sure that the UI layer doesn’t screw the data up 12 donderdag 9 juli 2009
  13. 13. 2. TIPI XML BASICS » tipi syntax Tipi syntax — Tipi applications are written entirely in XML and meant to be easily understood and read (!) by humans eyes Addressing semantics — how to address attributes, properties and other parts of your UI in Navajo expressions Functions — perform common tasks using custom functions Sample Tipi script — what does a simple screen look like 13 donderdag 9 juli 2009
  14. 14. TIPI SYNTAX » expression semantics Tipi files are usually structured so that each window, or dialog has its separate file, although files can include one another if necessary Each UI element has its own XML tag containing a custom set of attributes. E.g.: a <c.window> element has attributes for “icon”, “height”, “title”, etc. Tipi screen definitions are hierarchically defined. Using XPATH-style expressions different parts of the UI can be addressed, e.g.: //desktop/personWindow/tabs/addressTab/addressToolbar/addAddressButton:icon 14 donderdag 9 juli 2009
  15. 15. ADDRESSING SEMANTICS » functions Address references are placed between {curlies} to make sure they’re picked up by the Tipi parser They can refer to components, resources, navajos, properties or attributes: <tipitable.doExcel path=”{component:/../myTable}” /> <d.window icon=”{resource:/icons/icon_small.png}” /> Actions sometimes address elements directly, and sometimes refer to their locations (cf. pointers), suffixing them with “ref”. E.g.: <set value=”true” element=”{attributeref:/../myButton:enabled}” /> 15 donderdag 9 juli 2009
  16. 16. FUNCTIONS » sample tipi script The Navajo expression parser also supports the use of functions to manipulate data, attributes, or strings. E.g.: <set value=”ToUpper(‘Hello World!’)” element=”{attributeref:/.:title}”/> <c.panel id=”myPanel” border=”CreateTitledBorder(‘Person details’)”> <set value=”GetInitials({property:/ProcessGetPerson:/Person/FirstName})” element=”{propertyref:/ProcessGetPerson:/Person/Initials}”/> <injectNavajo navajo=”MergeNavajo({navajo:/relation/ProcessSearchOrganizations}, {navajo:/ProcessQueryWorkingSet})” service=”ProcessQueryWorkingSet”/> 16 donderdag 9 juli 2009
  17. 17. SAMPLE TIPI SCRIPT » working with tipi personSearchWindow » see Eclipse 17 donderdag 9 juli 2009
  18. 18. 3. WORKING WITH TIPI » managing layout Managing layout — a complex UI structure can be created using a combination of UI elements and layout managers Managing UI logic — typical usage of events, actions and listeners to create basic application flow Managing data — how to fill up your UI with actual data, and how to pass data from one place to another 18 donderdag 9 juli 2009
  19. 19. MANAGING LAYOUT » ui elements When creating a user interface you need not only say what elements your screens are comprised of, but also how these elements relate to each other For this purpose a simple hierarchy is not enough, next to UI elements we need layout managers, e.g.: buttons in a toolbar should be rendered from left-to-right the person window is divided into 3 columns when resizing a window, we want the memo-field in the bottom to stretch, but other fields to keep their current width and height 19 donderdag 9 juli 2009
  20. 20. UI ELEMENTS » layout managers UI elements are structured in such a sense that some elements act as parents or children of others This helps to group elements that are related, and makes it easy to address them A window contains a panel and a toolbar. The panel in its turn contains a table and some input fields. The toolbar contains a set of buttons 20 donderdag 9 juli 2009
  21. 21. LAYOUT MANAGERS » managing ui logic Tipi supports a number of layout managers each suitable for different purposes. The layout manager doesn’t define what is being displayed, but how the actual UI is rendered. Some examples: <l.flow> <!-- displays elements from left-to-right --> <l.border> <!-- expects children having “North”, “Center”, “South” contraints --> <l.vertical> <!-- put each new element on a new line --> <l.mig> <!-- can set complex rules such as colspan, gaps, fillx, etc. --> 21 donderdag 9 juli 2009
  22. 22. MANAGING UI LOGIC » actions From the moment an application is started, events are being triggered and actions are being fired. UI designers want to manipulate the way users interact with the application and control which elements actually listen to which events 22 donderdag 9 juli 2009
  23. 23. ACTIONS » event listeners Actions come in two broad categories: general actions manipulate the UI elements, logic or data. E.g.: <showInfo text=”‘Hello World!’”/> <callService input={navajo:/InitSearchPerson}” service=”ProcessSearchPerson”/> element-specific actions, implement methods of certain UI elements. E.g.: <tipitable.doExcel path=”{component:/../myTable}” /> <window.instantiate id=”personWindow”/> 23 donderdag 9 juli 2009
  24. 24. EVENT LISTENERS » service listeners Typical events that we would want UI elements to listen to are: <onInstantiate> <!-- what happens when the window is opened --> <onActionPerformed> <!-- what happens when a button is pressed --> <onValueChanged> <!--what happens when some field is changed --> But many more elaborate ones exist. To name a few: <onFocusGained>, <onDrag>, <onKey>, <onGeneratedErrors>, … 24 donderdag 9 juli 2009
  25. 25. SERVICE LISTENERS » managing data Components that display data, should be told what data to listen to. In its most basic form—where a component listens to an incoming Navajo service —this is implemented by adding the “service=…” attribute: <c.panel id=”myPanel” service=”ProcessSearchPerson”> <l.flow> <c.label text=”‘Lastname : ‘“/> <c.property id=”lastname” name=”Person/LastName” /> </l.flow> </c.panel> the lastname property only loads when somewhere (!) an action fires the ProcessSearchPerson service call 25 donderdag 9 juli 2009
  26. 26. MANAGING DATA » properties Apart from the structure needed to build a proper UI, it is the data which fills it with actual content Although other more elaborate samples can be found, most content that the user sees falls in the broad categories of properties and tables Next to visible data, we sometimes need variables to store invisible content or to keep certain values independent of screens that have been opened and services that have been called 26 donderdag 9 juli 2009
  27. 27. PROPERTIES » tables Properties in Tipi are directly mapped onto properties from Navajo services Since XTML also contains metadata, Tipi automatically renders their types correctly. Certain attributes can be set on properties to: override the ones supplied in XTML <set type=”money” element=”{propertyref:/ProcessSearchPerson:/Person/Extra1}”/> render properties differently. E.g.: <c.property name=”Person/LastName” enabled=”false” label_indent=”120” /> 27 donderdag 9 juli 2009
  28. 28. TABLES » variables Displaying an array of data is most commonly done in tables. Tables map on (array) messages in XTML. The different columns in tables adhere to the types of the properties provided, but can be overridden <c.tipitable service=”ProcessGetPersonAddresses” messagepath=”Addresses”> <column name=”StreetName” /> <column name=”HouseNumber” label=”Nr. + toev.”/> <column name=”ZipCode” size=”100”/> <column name=”City” /> </c.tipitable> 28 donderdag 9 juli 2009
  29. 29. VARIABLES » managing a tipi project There are two ways to pass variables in Tipi: set the value of a property in a Navajo service and use this as input for another service call. E.g.: <set value=”{property:/../myTable:selectedMessage:PersonId” element=”{propertyref:/InitGetPerson:/Person/PersonId}”/> set a global variable and later use this variable to either check certain conditions, or to later pass it on in a Navajo service. E.g. : <set value=”‘myUserName’” element=”{globalref:/userName}”/> 29 donderdag 9 juli 2009
  30. 30. 4. MANAGING A TIPI PROJECT » project structure Project structure — what does a Tipi project look like Running and debugging — how do developers work on Tipi Deploying applications — how to put your project online 30 donderdag 9 juli 2009
  31. 31. PROJECT STRUCTURE » running and debugging Setting up a Tipi project structure is easy. Only three folders are necessary: /lib : contains the core libraries /tipi : contains the Tipi .xml screen definitions. The first sc /resource : contains icons and other resources In the “Runtime configuration” (using Eclipse), set the Main Class, the Tipi file to start in (commonly start.xml), a Navajo Postman server URL, and a default look-and-feel 31 donderdag 9 juli 2009
  32. 32. RUNNING AND DEBUGGING » deploying applications Since Tipi screens are meant to be created in a XML editor, only one XSD schema is used to validate input Runtime errors and debugging information should be checked in Eclipse’s console Tipi screens can be changed while running them, a simple flush via a keyboard shortcut—without restarting or re-compiling—is enough to check and test the latest changes. This makes for extremely fast development 32 donderdag 9 juli 2009
  33. 33. DEPLOYING APPLICATIONS » extending tipi When deploying Tipi to a Java Swing desktop application, Java’s Web Start mechanism is preferable Java Web Start wants the jar files to be signed. The ANT build.xml script takes care of this To run a Java Web Start project a .jnlp file is needed (essentially a sort of runtime configuration) Tipi screen definitions are loaded runtime, so can be changed without the need for an actual “deployment” or (visible) download by the user 33 donderdag 9 juli 2009
  34. 34. 5. EXTENDING TIPI » customizing appearance Tipi is written in Java and easily extendible with custom … : Components — e.g. a <c.sourceviewer> was created to easily switch between the XML source view of a Tipi component and its parsed representation Functions — e.g. ScaleImageMax() was added to prevent people from uploading images that were too big Events — e.g. to support catching the event of people pressing the ‘enter’ key on certain input fields <onKey> was added to property elements Actions — e.g. <mergeNavajo navajoA,navajoB service=”navajoC”> was added to support working sets 34 donderdag 9 juli 2009
  35. 35. 6. CUSTOMIZING APPEARANCE » how it all ties up The actual look-and-feel of a Tipi application is not being defined in the application itself. Tipi only represents the form of an application, not its representation When deploying a Tipi application as a Java Swing application, a multitude of 3rd party themes and skins can be chosen from. E.g. Substance (current), Nimbus, Metal, etc. To further add to the idea of a Filthy Rich Client Tipi can be extended by a number of effects and transitions, such as 3D flipping panels, macbars, macbuttons, peeling windows, etc. 35 donderdag 9 juli 2009
  36. 36. END Questions? More about Dexels and the Navajo framework can be found at: www.dexels.com www.navajo.nl Feel free to call us at +31 20 490 4977 or mail us at info@dexels.com to ask for further information donderdag 9 juli 2009