Web App Development Overview

Part 1: One Approach


Contents

Introduction
The qooxdoo JavaScript Framework (and Lazarus)
Adding a Pascal Server App
Non-visual UI Design

Part 2: Creating a Map App with Pascal and "Canned" JavaScript
Part 3: Using a Web App in a Pascal Desktop App
Part 4: Writing a Mobile Web App with Pascal


Introduction

A Web app typically consists of two parts: a client-side app of HTML and JavaScript that runs in the user's browser and a server-side app that can be developed with virtually any programming language. The two apps communicate with each other: the client app makes requests for data and the server app responds to the requests by returning data.

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)

The Fish Facts Web app was developed with the qooxdoo JavaScript framework and the qxotica package for the Lazarus IDE. Once added to the Lazarus IDE, you can create a qooxdoo app and its boilerplate code (just use File | New), as well as edit and check the syntax of the client app's JavaScript, all from within 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 choose Run | Compile with a qooxdoo project in Lazarus, it runs qooxdoo's generate.py script to check the JavaScript syntax and generate the files needed to test the app locally by opening its index.html file in a browser. It does this by specifying the "source" job when it runs generate.py.

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):

You specify a job to indicate which server URL to use. For example, if you specify "source-usecgi", the app will use http://localhost/cgi-bin/cgigateway.cgi so you can test it locally. If you specify "build-usecgi" when you're ready to deploy, the app will use the URL of your actual Web server (also defined in the config.json file). The "usephp" jobs indicate to use the PHP server app rather than the Pascal FCGI app.

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

Here's a screenshot of the Fish Facts project's DetailPage.js file opened in the Lazarus code editor:

[Image] goes here

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.


Copyright 2016 by Phil Hess.

macpgmr (at) icloud (dot) com

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

Code syntax highlighting done with highlight.js.