Web Page Integration

Your Web pages can launch iNetWord in several ways:
  • A link
  • A button that submits a <FORM>
  • A Location: redirect header
  • Within a <FRAME> or <IFRAME>

 

In all cases, you control iNetWord's functioning using CGI parameters imbedded within the iNetWord URL. Such CGI parameters can trigger iNetWord to create or open a certain document, can control iNetWord's appearance, and communicates other operational values to iNetWord.

The CGI parameters travel to the iNetWord server, get processed and combined with the iNetWord configuration there, and then transmitted to the iNetWord program just launched and running in your customer's browser.

This chart and numbered explanations illustrate how iNetWord can be embedded and controlled by your Web application or service.

 

 

 

Your Application

Your application consists of interlinked Web pages and possibly a wide variety of components and interfaces. You have the choice of embedding iNetWord within your pages with FRAMES or IFRAMEs, or launching iNetWord in its own window. Both techniques offer control over iNetWord's look and functioning.

When you instantiate iNetWord in a FRAME, IFRAME, or separate window, you specify the URL of the iNetWord server. This URL contains the CGI parameters.

CGI Parameters

The URL you launch iNetWord with can contain several CGI parameters to control its functioning. CGI parameters can be passed by either GET or POST methods. By default iNetWord opens editing a new unnamed document based on the user's 'blank doc.html' template.

Config File

The iNetWord server contains one or more configuration files which configure all aspects of iNetWord's operation. The configuration settings given in the CGI Parameters override the values in the configuration file. The CGI parameters can specify an alternate configuration file to use. This capability enables a very large number of complex configurations to be utilized.

iNetWord Server

The iNetWord server generates the HTML and script, based partially on the specified configuration, and emits it to the iNetWord FRAME, IFRAME, or browser window. There are many server connection points and operations not depicted in this diagram.

The iNetWord server communicates with the files pane by fulfilling frequent requests to refresh the entire pane. This keeps the files pane current, displaying the most recent set of files and folders. Configuration and operational settings can also flow through this avenue to the iNetWord editor.

The iNetWord server generates the editor code and UI just once, even possibly during frequent file opens, saves, and publishes. This editor persistence is one of the reasons iNetWord to feels fast and responsive to the user. 

Files Pane

The iNetWord Files Pane is a default interface for login and file browsing. Many applications will replace the iNetWord files pane with the login and file browsing interfaces they already have.

JavaScript API

The iNetWord Files Pane operates with the iNetWord editor by calling the editor's JavaScript API. This API offers methods for creating and opening files, inserting pictures and objects, logging in and out, and transmitting arbitrary configuration settings.

iNetWord Editor

The iNetWord Editor can live in an IFRAME, FRAME, or within its own browser window. Its operation is completely controlled by the configuration settings it receives from (7), (9), and (11). Its operation is tied closely to the Server (5) through Ajax communication channels not depicted here.

Your application can control iNetWord using the same JavaScript API the Files Pane uses. You can use iNetWord's JavaScript API from just your application, just the Files Pane, or both simultaneously.