Framework Components:

This framework has 3 major components: host environment, constructors, and the application.

HOST ENVIRONMENT:

The host environment is defined in the hostEnv.js file. It provides the following services to the application and constructors:

io

provides communication with the server via cookies, server push, and XMLHTTPRequests [ POST | GET | DELETE]

errors

provides global exception handling with a cookie-based talkback system that logs client errors to the server.

state

saves gui state on server and restores it from the server.

JSON

json de/serializer

browser detection

detects platform and user agent

drag and drop

handles all underlying drag-and-drop functions ( you can think if it like an X-Y shipyard crane over the whole canvas). To get specific behaviors, this system passes events through to the specific drag-drop handler of any grabbed object.

skins

system for changing appearance and even layout on the fly.

constructors

dynamically loads constructors as they’re needed, and plugs them into host for the next use. Many constructors (will) require CSS class definitions from constructors.css, which is located in each skin definition.

context

keeps tack of which panel, dialog, etc. is currently focused. This way, events like keystrokes and right mouse clicks can have context-specific results.

event

routing routes key events to the currently focused panel, dialog, etc.

panels

the larges structural element of an app, features a cascading resize system for handling changes in the gui.

global resize

(this is occluded in the app) a global resize function that calls the cascading resize functions of panel contents.

global closer

(this is occluded in the app) a global

The host environment also provides a diverse collection of small utilities. Check the Natural Docs documentation for more detail.

CONSTRUCTORS:

Constructors are found in the *constructors* directory. They are used to create complex GUI elements and useful JS libraries. They are loaded, dynamically and automatically, from the server as they are needed. They only need to be loaded once per session, as they are stored in memory in host.constructors.

Each constructor takes one parameter - a JS object containing name/value pairs of all params needed by the constructor. Historically, CSS class names have been required by many constructors. This is very cumbersome, as some constructors require more than 20 class names. In the new system, all constructor class names are pre-defined in the constructors.css file in each skin definition. The constructors will still accept references to CSS rules, but they will now be optional parameters. This transition is still taking place as of this writing.

It's not just the application that uses the services of the host environment. Constructors may have their own drag/drop handlers, key handlers, context menus, and save/restore state functions.

Some constructors have custom data formats in which they expect to receive their content.

Some constructors have their own resize functions, making it easy to "right-size" them after changes to their inner state or the size/position of their DOM parent.

APPLICATION:

While the host environment and the constructors are generic, re-usable libraries, each application is highly specific and unique. But there are some common elements we can expect. For this example, I'll assume we're palcing out application code in a JS namespace called app.*.

3 layers: data, display, and logic.

One could say that there are 4 layers: data, display, data logic, and display logic. But those last 2 tend to get mashed together in practice, so we can just call them logic.

The data you see in the display layer is an echo of the data in the data layer. Any changes to the data are first applied to the data layer, then the display is updated. In this way, data never needs to be parsed. And you can do anything you want to the display layer without losing anything important.

data

All of this data is stored in app.data. But this data may be in several formats - which brings us to the Data Cascade. Data from the server and various other sources might not arrive in an optimal, integrated format. So it will have to be converted into a Master Data Format used by this application. But some of the constructors might require a format (or data set) different from the Master Data Format. So the data is transformed once again to populate these gui elements. And this is the cascade: server data formats --> Master Data Format --> constructor-specific data. Changes to downstream data should be applied to the Master Data Format and cascaded downstream, or even written back to the server, re-loaded, and cascaded from there. When dealing with a lot of data, it's best to formalize this cascade early. It can get hairy otherwise.

gui (display layer)

The gui is laid out using the concept of 'panels'. Panels are divs with extra properties and behaviors that connect them with the services host environment. These are a empty rectangular containers used for layout and to track context. They may have their own keystroke behaviors and context menus. GUI elements are placed within the panels and inherit their context (need to add detail later). Each gui has a global resize function that lays out the gui based on the browser window size, gui state information, and other factors. It may also call the resize functions of gui elements embedded with the panels. In future development, the skin system could contain different resize functions for each skin, allowing completely different layouts for each skin.

Each gui has a global closer function. This function closes menus, floaters, and other momentary gui elements in response to a mouse click anywhere in the gui. This is included to duplicate the expected behavior of desktop guis.