Web client applications
–
by Gérard Verron - June 2001

0 What is this?...

0.1 History

The Web client applications concept follows ePlanning:

• I wrote ePlanning because I wanted a light utility similar to Microsoft Project, of immediate use, and yet multiuser, so that my correspondents could review and return me a planning revision in a few minutes as a workgroup member, without having to use any application on their computor, and without having to be hooked up on a server.
• After ePlanning, I wrote eTablor to provide web estimatings for Project works, and I came out with a spreadsheet like resource.

Time had come to provide a unified environment for this development. Although I am not a programmer, I found useful to bring a contribution on this subjects by writing generic script lines that could be easily placed on top of such applications, so that they could be easily extended.

Strangely, this idea of autonomous dhtml applications had not yet been developed. I discovered that what was called as web applications were merely web pages parsed on the server, according to the commonly used client/server architecture; which is usually called the "light client concept":

1. Till recently, many large administrations and institutions were blocking the script capabilities of their PCs, to prevent "Java applets" and other portable software to access their systems.
2. Also, the difference between the two mostly used browsers (Netscape and IE) was such that only low level, commonly adopted html could be used.

This trend is slowing. The distinction between scripting languages and other languages is now made by most users, and, with the advent of NS6, cross browser development is becoming a reasonable goal.

Consequently most PCs are now allowing javascript on their browsers, and users are more and more willing to develop their local html resources without having to be hooked up on the internet, and without having to install many applications on their PC; "The light client dictat is breakening".

For this, DHTML is the best solution: it allows very fast compact code, and almost immediate and satisfying rendering (JavaApplets are too slow because not cached in memory, unsatisfying in screen rendering, and messy in code development).

Microsoft provides a framework and an "hta" attribute for web client applications, but it remains a closed undeveloped technology which does not bring much resources.

The "client application" concept is the result of my work on this subject. It write it to contribute to this evolution, and to share experience in the development of such client applications.

 

0.2 Aim of this document

The aim of this document is to provide a framework and examples for Web client script application. It contains "How to..." rules, and explanations on the dispositions that I have developed on this subject.

It will be a constantly evolving document, as these dispositions are at development stage

Basic common sense rules are proposed to be discussed in the Web client application forum.

Client-server interface is not discussed on these pages, as client applications develop mainly local browser resources. Yet all the client dispositions can be transposed to equivalent server functions when required for particular needs.

Web client applications male heavy use of client-side scripting, which is becoming a W3C development as defined in http://www.w3.org/TR/REC-html40/interact/scripts.html

 

0.3 Innovations

0.3.1 Functional innovations

Web client applications develop the following functional innovations:

• "All in one" concept: complete applications, with data and interface can be included in a single web page
• "Autonomy": Web client applications should be edited and exchanged without make use of a web server
• "Portability": Ultimately client applications should be used on W3C compliant browsers.

0.3.2 Technical innovations

This site contains some technical innovations that you will be able to see only there (at least at issue date):

• Dynamic client windows generation and management
• Cross browser dynamic styles management by scripting
• Automatic table of content generation
• Cross browser access to the client file system (under development).

 

0.4 Download

This file is also an "all in one concept" for easy download (except for images). Have a view at its header script, and copy it for your own use as it includes a useful "automatic toc" resource, which provides immediate "on the fly" generation and display of a document table of content.

The best way to use Web client applications is to take a demo file and adjust it to suit your needs. All I ask is to keep the top tags and its dedication to the Iraqi civilisation who has inspired the development of this web concept.

View http://eplanning.free.fr to see these demo files.

 

0.5 Limits

A unified client interface can start to be developed, as NS6 is becoming more serious about DHTML rendering since it is being replaced by MOZILLA....

However several limitations remain for mozilla based browsers:

1. Unstability; Mozilla/NS6 is still unstable and blocks often unexpectidly.
2. Slow responsiveness: Under windows, NS 6.1 remains painfully slow in screen rendering. Hopefully this should be better under Unix/Linux.
3. No direct file management access:till now, I have not been able to access "FileSystemObject" from NS6. Sorry, the only way found is through the sluggish "java.io.File" class for javaenabled browsers...
4. Too many bugs in the CSS management prevent correct implementation of javascript style management.
5. No support of DEFER scripting in Mozilla although this is a W3C script property (http://bugzilla.mozilla.org/show_bug.cgi?id=55560)

Mozilla openness deserves support. Also, checking the code compliance useful academic task, as NS6 is very strict for the W3C syntax that it adopts .

Following these cross-browser checkings and despite the strict W3C compliance of our code, present bugs in Mozilla prevent a correct display of eTablor applications. We hope that next versions will rectify this soon.

---

1 Introduction

 

1.1  Existing examples

1.1.1 Server based

Typical web applications - server based - are found at

http://www.hyperoffice.com/

www.blox.com/

webfx.eae.net/webboard/

Web client applications depart totally from these applications that rely deeply on the server, and that leave the client in a situation of heavy dependency

1.1.2 Other examples

Preambles of "Windows-like” cross browser application interface  can be viewed at:

www.brainjar.com

www.dhtmlcentral.com (Thomas Bratta website)

Web client applications make heavy use of these examples, and extend them by:

• combining the menu and the windows resources,
• providing Netscape with real dynamic windows thanks to emulation of html insertions

1.1.3  dhtml GUI

Dhtml GUIs (Graphical Users Interface) are a developing matter, an interesting example of CrossBrowser Technology is at:

www.dhtml-guis.com/code/by/module/

Notably they have developed a "Poem" example (try the game ) where the data is saved in a cookie instead of the file system.

 

1.2 String exchangeability

In addition to the introduction of a windows like application environment, web client application intend to address a more fundamental concept, the one of "data/application exchangeability".

To understand this, WebClient applications consider:

    - the "data" strings
    - the "client interface" strings

as equivalent but distinct text strings that can permanently generate scripting objects at runtime. The "client-interface" as well as "data" can consequently be dynamically exchanged within the same document.

This is done simply by appending or adding scripts to the document at runtime, and by distinguishing the data strings from the other application scripts. This capacity makes use of the "DEFER" script attribute and provides WebClient applications with dynamic customization capacities (customize menu).

This capability needs a high consideration, as it distinguishes web client applications from traditional compiled applications.

• Traditional compiled applications have fixed rigid compiled interface. This limits their development to internal extensions. They have consequently continuously increased their size, at the point where they all look like kinds of "dinosaures"...
• In the contrary  imagine what will be the sofware industry when applications will be able to shift their whole interface and replace it as if it were a dataset....This dream can come true and become commonly used with web client application. This will give them unlimited flexibility and development possibilities...

---

2 Features

 

2.1 Technical features

• Windows like interface: The concept of the windows like interface is useful as it allows a preview of the application on mail browsers. Also, it prevents window spam openings on the client.
• Access to local file system

 

2.2 Fonctional capabilities

2.2.1 Autonomy

No server scripting or CGI programming is used, also calls of external Applets or VB components is avoided. Standard Javascript is exclusively used to avoid addition resources.

2.2.2 Compacity

To be immediately usable and fastly transferred, Web client applications are light and compact. Everything can reside in a maximum size of 200/300Ko .

2.2.3 Portability

• Scripts are grouped in libraries to be easily copied and transferred between applications
• Persistence of User settings is still in its enfancy

  - I do not like cookies which I consider as an intrusion, yet when applied at local level only, and strictly limited to the conservation of user settings, this may still be considered as a minimum harm

  - Behavior has to be implemented and developed

   

2.3 Architecture

• Data is placed on top to have easy view and access
• Display texts are placed just below the application styles to facilitate their translation in several languages.

 

---

3 How to build

You need almost no knowledge of javascript to build an application interface. You can use the script provided with a sample application as a "black box", and expand it to your needs.

The same does not apply as to the client data representation and application script development. These are left to your consideration.

This section will describe step by step, like a recipe, how to build up a web client application .

A web client application consists of three main blocks:

• The webClient windows library
• The application scripts libray
• The data structure

 

3.1. Windows library

3.1.1 Styles

All the styles are grouped in one same stylesheet, which is managed by script so as to group all the resources in a single document.

id style attribute (#men and #win), are indicated in front of each selector, also, clear descriptions are used so as to avoid any messy style confusion in the included documents

3.1.2 Hierarchical menus

Preferably leave the basic windows menu library, and insert the menu application scripts in the application library

3.1.3 Dialog windows

Prefer external dialog windows for any browsing with undefined external resource.

 

3.2 Application scripts

3.2.1 Application init function

Have a look at the sample, it appends the document in the following order

1. style sheet,
2. menus,
3. toolbar,
4. application windows
5. application functions

For application script appending, use an identifier (#app+whatever) for each application style rule to avoid messy problems.

3.2.2 Scripts

Grouped in a single script libraries for exchangeability and easy customization. I like to classify them by menu order order, with group names for easy understanding

 

3.3 The Data structure

It depends on the application. The data structure is presently displayed as a text string. XML representation will be the next step :

They form a set of arrays for eTablor and ePlanning applications. Savings are being done by getting the array elements, and building separate text-files from these elements, one for the style, one for the data.

---

4 How it works

 

4.1 Overview

4.1.1 Basic Idea

The basic idea of a web client application is autonomy. Everything can reside in a single web page so that it can be sent to non experienced user who should not have to bother with images or files attached to the application.

When the client wants to save or to mail its file, a script function collects the string scripts, the style strings, and the datacache. This builds a new html document which can then be saved on the client computor.

As the data file which is in cache is represented as a html string, a web client application can have the possibility to save and import

• either the datafile only.
• either the datafile with its application and display environment.

When opening a web application file, the scripts read the datafile, and keep it in memory so that it can be appended or modified by the client browser. 

 

4.1.2 Data and format management

Data and document formating management are distinguished by using script styles management; for this, I had to break Netscape undisclosed script access to styles management (this is a scoop!....) sorry for showing Netscape addicted that their preferred developers are "crooks" who steal Microsoft ideas and who do not implement them totally. The shame on them for this old silly "InsertRule" function, which hopefully should be soon replaced by "addRule" with excuses.

 

4.2 Saving and updating

Can be done on the client PC for IE based browsers only. As NETSCAPE does not implement the FileSystemObject which provides access to a windows PC file tree, use is made of the "java.io.File ".

The File class is intended to provide an abstraction that deals with most of the machine dependent complexities of files and pathnames in a machine-independent fashion. It works for Java enabled Netscape users.

 

4.3 Upload & Download

Getting and posting data to distant servers, require the opening of a separate instance (iframe or dialogwindow), to provide the necessary server interaction. As a consequence, avoid application-windows for these transactions.

This also presumes that the server has a server script to handle this interaction.

4.4 Mail posting

You can post a web client application or its content directly from within the application.

At present stage, due to the limitation of the "mailto" client protocol, the script makes use of a php server script.

 

4.5 Customizing

It is the most striking feature of web client applications. It is done by getting javascript files and adding them to the javascript document objects . The innovation is very simple once it is disclosed; it consists only in creating a temporary child dialog window, which is used as a temporary container of the new http instance (avoid screen refresh on the parent window) , and having the main file preconfigured for this transaction process.

---

5 GUI components

 

5.0 The Problem

When exchanging documents by mail, if attached files are enclosed in an accompanying folder, a great chance exists that this folder is forgotten or badly copied in a subsequent process, then the application becomes unusable.

To alleviate this, each application document should include its complete UI (User Interface), including its images, therefore these images have to be scripted. This UI must be compact so as to exchange light portable application documents.

 

5.1 Basic components

The following "Graphical User Interface" basic components have been developed and are included in the application header scripts.

• Drop down menus
• Toolbars
• Scripted images
• Application windows

To shorten them, string return functions are employed each time a string is repeated. For easy view, these functions are classified by menu display order in each script library.

 

5.2 Drop down menus

Many types of drop down menus are available on the web, most of them made of long-tedious script. Ours is compacted in 4 functions and 20 self understandable script lines.

 

5.3 Toolbars

They are inspired from webfx.Drag-drop is only initiated for one tool-bar (to be developed)

5.4 Scripted images

Pseudo graphical script icons are used, by making use of a hover effect on a link tag.

Due to NETSCAPE sectarian attitude against "Wingdings", "Webdings", "Dingbats" and other web characters, script icons are mainly developed with unicode characters. However, even on this NETSCAPE is very limited in UNICODE display in its basic configuration. So this is somehow a headache...

(view http://www.hclrss.demon.co.uk/unicode/for more information)

The best to develop scripted images is to look at existing ones and adapt them.

 

5.5 Applications windows

They are derived from Thomas Brattle script (www.dhtmlcentral.com).

At present stage, they rely heavily on "Divisions", rather than "Internal frames" as frames are not yet supported by "Outlook express" or "Mail messenger" . (Also to avoid NS6 buggy Iframe implementation)

Instances of several internal frames inside application windows has to be considered to allow the use of concurrent instances within one application. (I would like Iframes with scriptlets like with the menu3 of http://webfx.eae.net ...but once again, Netscape sectarian attitude)

Basic scripting concepts

1. Keep the window scripts in its library.
2. Keep the script contents in the main file: This allows to use the script for several dialog windows
3. Group the scripts in component libraries for easy reusing
4. Use

 

5.4.1 Open/Save window

It is a javascript imitation of the Microsoft "common Dialog Window" which I have written to provide immediate access to the host filing system and to follow the objections of users who had to install this "Microsoft common Dialog Window" on their PC, as it is not directly accessible from an IE5 browser window.

 

The present script provides in a 6Ko script almost the same functionality as the Microsoft 110Ko "Common Dialog" window.

Pseudo-icons are presently used to avoid the importation of images. We should find the way to use the system icons (ideas are welcome for that)..

5.4.2 Post Dialog window

Owing to the present limitations of the "mailto" protocol (file attachment impossible), post a file makes use of a php3 script to send the application.

This is presently the only situation where Web client applications need the use of a server. This limitation should find quickly a solution as it should be easily possible to parse a multipart smtp header from within a client script.

The present php3 script sends the whole html string as an attachement. As a consequence, the browser of the recipient displays immediately the web application.

Even more, this document can be revised from this mail browser. This gives a striking effect, as no other compiled application can do that!

 

5.5 Body element

The body element is almost empty: It is mainly a container which includes the following divisions

• On top the "Menus" division : drop down menus and menubar menus
• Eventually a TOC division on left
• Low collapsible divisions as required by the application

 

Use of frames: Presently limited because the buggy ns6 is resisting anything but the topmost z-index for iframe generation, hiding dropdown menus....

Textarea input boxes are used instead of Iframes "design/edit mode" to provide compatibility to NS users. .

 

---

6 Author's Statement

You may use the technique published in this paper as you want. You may copy the scripts provided here, modify them and use them for any purpose.

The only condition is that if you publish web pages that use this technique you point to its author at a suitable place and don't remove the Author's Statement,(especially its dedication to the Iraqi population whose dignity - after more than 10 years of monstruous embargo - has inspired these lines).

If you publish web pages that use this technique it's your responsibility to handle possible bugs even if you didn't modify any script. I cannot promise any support (I am a Construction Manager not a programmer).