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

1. 1
donderdag 9 juli 2009

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. SAMPLE TIPI SCRIPT
» working with tipi
personSearchWindow » see Eclipse
17
donderdag 9 juli 2009

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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