eWebOS...
Autonomous web documents
by Gérard Verron - November 2001

0 What is it?...

0.1 History

The concepts of "Autonomous Web Documents", and "ewebOS" follow the writing of 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. Then I wrote eDitor to show the extent of this concept

Time had come to provide a unified environment for this development. Although I am not a programmer, I submit the following lines as a contribution on this subjects to explain the dispositions that I have implemented for this undertaking.

Strangely, till now, the idea of autonomous web documents (or autonomous web applications ) has not yet been developed. Presently what is called as web applications are merely web pages parsed on the server, according to the commonly used client/server architecture; which is usually called the "light client concept":

Fortunatly, "The light client dictat is breakening",  as users rightly find unbearable to be "hooked up" on a server while using them.

The "autonomous web document" concept is the result of the dispositions that I have developed to break this dictat. It write it to contribute to the evolution of this breakthrough, and to share experience in the development of such subjects.

 

0.2 Aim of this document

The aim of this document is to provide a framework and examples. 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 autonomous web documents forum.

0.3 Innovations

0.3.1 Functional innovations

The following functional innovations are developed:

• "All in one" concept: complete applications, with data and interface can be included in a single web page
• "Autonomy": Autonomous web documents should be edited and exchanged without make use of a web server

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

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 autonomous web documents 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

0.5.1 Using MOZILLA

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.... (Personally, I consider NETSCAPE developers as criminals, because their deadly sectarian attitude is largely responsible for the marginal share of LINUX).

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)

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

0.5.2 With "outlook express"

Presently outlook express does not provide an access to the file system object; Sorry I can do nothing against that.

---

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/
www.mywebos.com/
webfx.eae.net/webboard/

autonomous web documents and ewebOS depart 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)

EwebOS makes use of these examples for the display of its "pseudo-windows", and extends 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

Autonomous web documents intend to address a more fundamental concept, the one of "data/application string exchanges".

To understand this, Autonomous Web Documents consider:

    - the "data stream" 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 strings to the document at runtime, and by distinguishing the "data stream" strings from the other application scripts. At saving time, the autonomous document collects the "data stream" and appends it with the script strings. This forms a document which can be saved locally or on a distant server. This mechanism can also be extended as well to the application script by making use of the "DEFER" script attribute. It provides Autonomous Web Documents with dynamic customization capacities (customize menu).

This capability needs a high consideration, as it distinguishes autonomous web documents 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 autonomous web documents. 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 additional resources.

2.2.2 Compacity

To be immediately usable and fastly transferred, autonomous web documents are light and compact. Everything can reside in a maximum size of 100/200Ko .

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

A autonomous web documents 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 feature of a autonomous web documents is autonomy. Everything can reside in a single web page that 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 autonomous web documents 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 MOZILLA/NETSCAPE do not implement the FileSystemObject which provides access to a windows PC file tree...)

I have written a javascript imitation of the Microsoft "common Dialog Window" to provide immediate access to the local PC system.

 

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

 

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. This presumes that the server has a server script to handle this interaction, and that you are registered on this server.

The"common Dialog Window" developed for this is obtained from the server. It is similar to the Windows common dialog

4.4 Mail posting

You can post a autonomous web documents 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.

This is presently the only situation where autonomous web documents 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!

 

 

4.5 Customizing

It is the most striking feature of autonomous web documents. 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.

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.

Enough is enough: NETSCAPE sectarian attitude against "Wingdings", "Webdings", "Dingbats" and other web characters, can be overcome with unicode characters. However, even on this NETSCAPE is very limited in UNICODE display in its basic configuration. So this is somehow a headache..., and consequenly, at present stage, webdings are heavily used

(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).

1. Applications windows 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)
2. In the contrary, E ProjectOS relies heavily on internal frames

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, I face the Mozilla/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.6 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 Sharing resources

Sharing resources require the setting up of common server resources. The autonomous web documents concept is a powerful tool to develop a windows like serverOS interface.

6.1 ewebOS

E project OS provides intuitive access to repertories, files, and applications shared on a web project server.

6.2 eFileManager

E fileManager provides intuitive file management of repertories, and documents shared on a web project server.

It includes all the main functional of the windows desktop:

• Shortcuts
• Documents repository
• Drag&Drop
• etc...

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