Web App Development Overview

Contents

Introduction

With simple apps that don't need any code to be executed on the server, you might be able to get away with developing only the client-side app, assuming you can write a bit of JavaScript. The entire app can then be deployed from almost anywhere, including a Dropbox account.

For example, here's the venerable Delphi Fish Facts demo app done as a Web app. It's so simple it doesn't need a server-side app, just index.html, fishfacts.js, a few CSS files, and the biolife.json and .png files containing the data and pictures it needs. Click a fish in the list at the left to see its data and picture.

(Note that the document you're reading was designed to be viewed in a desktop browser. The app itself will adapt to any browser, mobile or desktop. If the embedded app above doesn't look right in your mobile browser, click here to launch it in its own browser window.)

The qooxdoo JavaScript Framework (and Lazarus)

Here's what the Fish Facts Application.js code looks like as created by qxotica from within Lazarus and used in the app without any modifications:

If you scroll down in the code, you'll see that it sets up a main page and a detail page, as well as a "listener" function that responds to the selection of a fish from the list and a function that responds to touching the Back button on the detail page when run in a mobile browser.

Here's the Fish Facts app's MainPage.js code. Starting with boilerplate code created by qxotica in Lazarus, additional code was added to set up the fish list and bind it to the data source:

Finally, here's the Fish Facts app's DetailPage.js code. Again, starting with boilerplate code, additional code was added to lay out the page and bind elements of the page to the data source:

Adding a Pascal Server App

When you're ready to deploy the app, you can run the generate.py script with the "build" job to combine your app's JavaScript with the qooxdoo framework's JavaScript into a single .js file. The resulting "build" folder can then be copied directly to your Web server.

Typically a qooxdoo project will have additional custom jobs. For example, the Unicodum demo app included with the qxotica package includes the following jobs (defined in its config.json file):

• source-usecgi
• build-usecgi
• source-usephp
• build-usephp

Since a qooxdoo client app doesn't "know" anything about the server app and the server app doesn't "know" anything about the client app making the requests for data, it's easy to switch between different server apps. The only requirement would be that they return the same data.

For example, here's the Pascal source for the main unit of the getunicode FCGI server app:

Scrolling down in the code, you can see that the app does only two things: if it receives the "blocks" query it returns JSON for the list of Unicode code blocks; if it receives a query of the form block=xxx, it returns JSON for the specified block's Unicode characters. All data is obtained from a Sqlite database on the server and converted to a JSON array.

Connecting the JavaScript client app's UI to the server app is the same as it was in Fish Facts. In Fish Facts, the code binds the UI elements to the URL of a JSON file on the server; in Unicodum, the code binds the UI elements to the URL of a server app that returns JSON. The code looks almost the same. For example, here's the code that binds the master page's list of blocks to the server app (compare it the code in MainPage.js above):

Non-visual UI Design

The code shown in the editor lays out the fish's picture and its two lengths (inches and centimeters). Note how there are no pixel values used to specify the location and size of the Image and Label controls used.

Instead, the three controls are laid out as follows: The labelLengthIn and labelLengthCm controls are added to a vertical "container" control (container2). Then the image control and container2 are added to a horizontal control (container3). Finally, container3 is added to the page itself. The result is the layout you see in the Fish Facts app above.

Note that you can use pixel settings if necessary. Typically you would add these as styles to the app's CSS. For example, in the above code, a couple of non-breaking spaces are prefixed to the HTML returned for the length labels to set off the labels from the picture. If you need something more precise than this, you could try creating a style with a margin-left property and assign it to the label controls via the control's addCssClass method.

Somewhat paradoxically, this kind of "non-visual" UI design often results in a better overall look, since it allows the controls to position and resize themselves "naturally", flowing and filling in the available space on whatever mobile or desktop browser is used to run the app.

macpgmr (at) icloud (dot) com

First posted June 11, 2016; last edited April 26, 2018.

Code syntax highlighting done with highlight.js.