Introduction

Here we detail the process of writing weblications. SashXB weblications can range from short utility scripts for individual use to full-featured applications. We'll start with some easy ones.

A Few Items Before We Begin

What's a weblication?

A weblication is an application that executes on the SashXB runtime. Weblications are built using Web technologies (HTML, JavaScript, XML) that can take advantage of native operating system functionality (file system, networking, user interface, etc.).

The SashXB runtime provides a gateway to this functionality by exposing it to the weblication's JavaScript environment. In this way, you can seamlessly intersperse calls to native functionality within your normal JavaScript code. This approach has several benefits:

You're no longer limited by the constraints of JavaScript functionality. Do you want to save a file to the disk, or store something in the system registry, or pop up a complex native UI? Go ahead.
Faster development than projects written in traditional native languages. Since the native functionality is exposed in abstracted form, even difficult tasks (such as establishing a multi-threaded FTP connection) can be accomplished in one line.
Increased ease of deployment. SashXB provides point-and-click, fully customizable installation, updating, and uninstallation locally or from the web.
Comprehensive security model. Users will be more inclined to use your application because they don't have to trust it in the same way they have to trust native binary programs: SashXB gives the user the option to specify exactly how much native access your weblication has.

Anatomy of a weblication

Conceptually, a weblication is a container for one or more "actions", which are the actual blocks of code that do things. This structure allows you to package several similar components (say, a stock ticker in the GNOME panel and a stock selection utility on the desktop) into one installable package. Each action consists of script (whether in an HTML document or a JS file) and resides in a particular "location", perhaps on the desktop or in a terminal, or anywhere else. The weblication as a whole has security settings that you can suggest (such as "Allow sockets" if you're writing a finger client) but which the user must ultimately accept. It may also have resource files, such as UI definitions, HTML, or images, that can be shared among actions.

SashXB exposes native functionality through "extensions". Each extension encapsulates a particular aspect -- FileSystem, Registry, Sockets, XML, and so on. Your weblication may require the use of any or all of these; we say it is dependent on the ones it needs. Extensions can be distributed and installed much as weblications are. By checking a list of your weblication's dependencies at install time, the SashXB runtime can ensure that the user's system already has all the necessary extensions installed (and if it doesn't, the runtime will try to find and install them on the spot). You can find a list of currently available extensions on the SashXB website.

This list of dependencies, along with security, action information, a list of resource files, and any other metadata, is kept in a Weblication Definition File (WDF). We provide a graphical WDF editor to aid you in creating this file. For your own code, you can use any editor you'd like.

Locations

A location determines where your weblication will live. In designing your weblication, you generally want to start by determining what location(s) you're going to use for your actions. There are two fundamental types of locations: those that use an embedded Mozilla and those that use just a JavaScript interpreter. For the former, you design your weblication as a web page, putting stuff in an HTML file and writing your Sash code between <script> tags within that file. User interaction is done through standard JavaScript callbacks (with the one difference, of course, being that you can do far more complex things with your Sash calls). For the latter, the JavaScript engine, you write Sash code directly into a .js file. Unlike the embedded Mozilla approach, there's no built-in UI, so it's up to you to choose what extensions you'd like to employ to create your user interface.

Where can I download sample weblications?

The easiest way (next to this guide) to learn weblication writing techniques is to look at the source for other weblications. The SashXB weblication gallery contains a number of weblications available for download. If you're planning on writing a weblication, check out a few to get an idea of what weblication source code looks like. They also serve as good examples of how to get your weblication to interact with a GUI and how to use various extensions.

Will Sash For Windows weblications work in SashXB (and vice versa)?

Sash for Windows is a closed source analogue of SashXB that runs on Microsoft platforms. Since both expose native functionality to JavaScript in the same way, it is possible that a weblication written on on platform will work on the other, provided that the extensions it depends on are available on both. This is not an overarching goal, however: there is no guarantee that any weblication written for Windows will work on Linux, or vice versa -- because then we'd have to ensure that every extension is written for both platforms. That would hamper the power of both programs; only the common denominator functionality of the two OSes could be supported.

That said, however, extensions that are potentially cross-platform tend to be implemented as such, and share the same API on both platforms. So if you are careful to design a weblication that depends on extensions that exist on Windows and Linux, chances are it will work on both with little or no modification. The Checkers weblication is one example of this.

Wing Yung, AJ Shankar

Last modified: Thu Apr 4 14:31:54 EST 2002