Developing Webtop Applications

An overview of basic elements when creating a Webtop

A Laszlo Webtop can include various applications, each running independently of one another and each in its own window. The Webtop itself is an OpenLaszlo application that includes its own dock, window manager, skin, and applications. Because all Webtop applications are developed using OpenLaszlo, they reflect the rich, fluid nature of the platform itself.

Creating a Laszlo Webtop begins with a main.lzx file that contains the LZX <canvas> tag and references the webtop’s stylesheet, the libraries to include (framework and specific dock manager and window manager), and the applications that will run in the webtop.

The following main.lzx is an example of a webtop:

<canvas proxied="false" width="100%" height="100%" bgcolor="0x898989">
<debug x="302" y="546" width="400" height="200"/>

<!-- framework -->
<include href="../../framework"/>

<!-- skin -->
<include href="../../skin/gloss-default.lzx"/>

<!-- applications -->
<include href="modules/lzpix" />
<include href="modules/contacts"/>
<include href="modules/mail"/>

<contactswindow id="gContacts"x="5" y="45"
width="$once{Math.max(250,canvas.width*.2)}"
height="$once{Math.max(200,canvas.height*.9)}"/>

<lzpixwindow id="gPhotoWindow"
x="$once{Math.max(250,canvas.width*.2)+5}" y="45"
width="$once{Math.max(500,canvas.width*.5)}"
height="$once{Math.max(300,canvas.height*.9)}"/>

<mailwindow id="gMailWindow" x="$once{Math.max(200,canvas.width*.5)+5}"
y="45" width="$once{Math.max(200,canvas.width*.6)}"
height="$once{Math.max(200,canvas.height*.9)} "/>

<!-- include the onyx look with the non-branded splash -->
<include href="../../skin/marquee/onyx/without-splash.lzx" />

<resource name="dock_logo"
src="../../framework/resources/webtop_dock_logo.png"/>
<resource name="splash_logo"
src="../../framework/resources/webtop_splash_logo.png"/>

</canvas>

As the example illustrates, the main.lzx, like any OpenLaszlo application, starts with the familiar OpenLaszlo <canvas> tag and its corresponding end tag, </canvas>.

Following the <canvas> tag are references to the Webtop framework library, and an include of the desired skin for branding of the Webtop. Following the references to the framework and skin is the list of applications to be instantiated. In our example, three applications will be compiled into the webtop: Contacts, Photos and Mail. After the declaration of the applications to be included are optional application-specific tags that control the initial state of the webtop applications at startup time. The developer can specify which windows are initially open and how they are positioned.

Finally, the main.lzx file ends with optional includes to any LZX code. In the example above, this webtop will display a customized splash screen.

What is an Application?

Webtop Application

A Webtop application, as described above, is a set of OpenLaszlo classes that use a unique framework and APIs. An application may define zero or more windows as part of its user interface. It may also access zero or more data services either directly or through the Webtop server.

The Webtop server supports a plug-in architecture as an extensibility mechanism for incorporating new data services. Data is routed between the client and server through the client-side Data Manager and the server-side Dispatcher. The Data Manager provides Webtop applications with the ability to multiplex multiple data requests into a single server-side request to minimize bandwidth usage and network latency. Upon receiving a request from the Data Manager, the Dispatcher unbundles the multiplexed request and routes the individual requests to the appropriate application or data service.

The following sample code is an example of a very simple client-side Webtop application:

<application name="notepad">
<attribute name="title" value="Notepad" type="string" />
<command name="New Note" onselect="parent.newNote()" />

<method name="newNote">
new notepadNote();
</method>

<!-- @param model m: model to edit -->

<method name="edit" args="m">
var nn = new notepadNote();
nn.model.syncTo( m );
</method>

</application>

As the example illustrates, a Webtop application is simply an OpenLaszlo instance of the “application” class. In the example, an application named “Notepad” is being defined. The application defines two methods: newNote for creating a new note and edit for editing an existing note. It defines a specific “command” which if deployed with the app menu dock will cause a menu item to appear under the application menu in the dock.

What is a Skin?

Skinning allows a Webtop developer to modify the “look” via CSS and custom LZX code. It also allows the modification of some behaviors via CSS and choosing or extending dock and windowing classes.

Appearance

The screen below illustrates the default Webtop skin, called “gloss,” which offers multicolored windows.

Webtop with the default gloss skin

By modifying the CSS style, a developer may specify the color scheme for each application or a single color scheme for all applications. Icons for the Laszlo-built applications were designed so that they may overlay any particular color choice.

Designers may create new window skins by supplying a new set of resources. For example, the window in Simple Window Dock Manager section below uses the identical window class as the windows in Figure above, but a different CSS references alternate resources creating a very different look for the windows.

________________

Defining Windows in Webtop

Laszlo Webtop includes a standard window definition that has controls for maximize, minimize (send to dock), close, and resize. Note that the title bar is draggable. Windows may define optional “footer buttons” for application-specific behaviors.

Developers may define a new window class that offers different controls, defines alternate user interaction, or appears with a different form. New window classes simply subclass a base window class and automatically participate with the window manager and dock.

________________

Using Window Managers

Laszlo Webtop is designed for pluggable window managers. The current release ships with a standard layered window manager, which supports overlapping windows. Additional window managers are planned for future releases, which will support alternate space management techniques for the end user.

________________

Dock Design and Behavior

Developers can also define their own dock look and behavior. A dock view and one or more dock item classes define the look of the dock. Any LZX view can be identified as the dock view. Therefore developers have the flexibility to make the dock look any way they want, whether it be additional behaviors such as expanding and scrolling, or adding buttons, menus or dynamic information. Windows declare an associate dock item class, which is simply the visual representation of the window when it appears in the dock. For example, in Figure below, there are three dock items: Contacts, Photos, Notepad. Each is represented as an icon and title but could easily be a graphic. In addition, developers may choose to have consistent or unique dock items.

Sample Dock showing Laszlo Contacts, Photos and Notepad

A dock manager defines the behavior of the dock. Laszlo Webtop offers two dock managers and, of course, developers can write their own.

________________

Simple Window Dock Manager

Each window is represented as a dock item arranged horizontally in a row on the dock. Dock items appear on the dock only when windows are minimized and disappear when windows are displayed.

Simple Window Dock Manager

________________

Application Menu Dock Manager

Each application is represented with an icon and title on the dock. Each window is represented as a dock item that appears in a menu associated with the window’s application. Application menus may also contain commands specified by the application. This dock is designed to manage the complexity of having multiple applications that each have multiple windows.

Application Menu Dock Manager

Service Orchestration

The Laszlo Webtop framework offers data services that optimize client-server interaction, allowing developers to develop modular applications while reducing server load and creating a high-performance end-user experience.

Webtop client-server data transport

One key performance optimization for Ajax applications is to simply reduce the number of round-trips between client and server. The Webtop client data manager allows applications to batch unrelated requests, multiplexing multiple client requests over a single HTTP request. For example, different applications require dynamic information to display the initial state of the application. Separate Webtop applications can each define a request for dynamic application state that would be sent along with the login request. The Webtop Dispatcher (on the server side) dispatches the application requests to the appropriate service, collects all of the responses, and then sends them in one response back to the client. The client data manager then distributes the responses to multiple applications.

SmartObjects™

Laszlo Webtop introduces the notion of a Smart Object™. At a high level, this is the key to application interoperability.

Webtop defines a standard representation for “person” and “picture” objects, and any Webtop application can define its own data types. Once defined, any other application may leverage the definition and behaviors of the Smart Object™.

SmartObjects are internally represented by a “model” class.

Key features of SmartObjects™ include the following:

• Schema-tized
• Know the types and sizes of their fields
• Can be easily extended to support custom validation
• Change difference aware
• Know what has changed since last commit
• Identity notion
• Can create two representations of the same data
• Two model objects both update when changes to one are committed
• Improved data-binding
• Sophisticated modeling of relationships among data objects
• Hides the transport-level details of how data is received by the client
• Models are SmartObjects™
• Drag-and-drop: models integrated with drag manager
• Will be able to attach specific actions (e.g. send mail to a contact)

Data Models

In addition to the basic CRUD (Create, Read, Update, and Delete) operations, there is a well-defined data paging API. Client model and datalist classes support scrolling large lists, automatically fetching on-demand and maintaining an in-memory cache. To implement data paging for specific server data, a developer would implement a service that implements a well-defined API. A subset of the following operations may be implemented, if the client application does not surface UI elements for the full functionality.

• Filter: This action can specify a subset for a query by using a condition
• Sort: Services return query results in a default sort order, but clients can request alternate sort orders
• Paging by Offset: For sets that are too large to be loaded at once, the client may request that the response begin with a numeric offset
• Paging by Selection: In some cases, the client has an individual record but does not know its position in a new sort and/or filter combination. In such cases, the client can specify the result offset as a query.

Authentication / Single Sign-on

The Webtop framework provides the facility for users of a webtop to login and authenticate themselves. The choice of whether to require users to authenticate is the webtop developer’s decision.

The Webtop can be configured to support single sign-on (SSO) so that users only need a single identity and password combination. That means that when logging in, a user only needs to login once to gain access to multiple applications. The Webtop framework also includes “remember me” functionality that allows a user to login once and have the webtop remember him/her the next time he/she uses it.

Each webtop application may have its own authentication mechanism. For an application to participate in the SSO system, it must use the SSO APIs.

Participation in the SSO system

The above diagram illustrates how a Webtop application with a back-end data service participates in the SSO system. When the Dispatcher routes the login request to the application service, the application service requests the user’s credentials from the Webtop’s CredentialStore. The CredentialStore is a Java class that provides an interface for requesting user name and password. It is extensible to allow for external existing SSO systems or other alternatives to be plugged into any instance of a webtop.