The Adept Client Model

Adept is a client/server system based on web server technologies. Specifically it uses a browser as the container for the top GUI tier. So far this is no different from Apache and Tomcat - HTML along a TCP/IP wire. Many systems developed on these platforms use DHTML and JavaScript to provide frills and icing. Here Adept diverges from the standard model - it takes a step further and uses DHTML to provide shrink-wrap software like features to the web browser.

An Adept application is run in a 3-frame window. The top frame is a desktop where all the action happens. Below it is a narrow tab-bar frame for maximised windows. The communications frame is invisible for working applications, but shows while in debugging mode. It has an iFrame for server communications and space for log messages. It also has a number of debug specific links such as record and playback.

Panels

On the desktop there can be one or more panels holding forms, pages or any other form of browser supported displays. The panel itself consists of a label tab, border, resize point, menu and content iframe. When a panel covers the full desktop, it's label moves to the desktop tab area. Panels can be moved and resized - or programatically locked into place. Each panel can hold other panels allowing for a heirarchical grouping of applications and functions.

Menus

Any panel can have menu and button bars above the content. In most cases these will be full-screen parent panels containing other panels with more application detail. This, however, is convention and not restricted by the application. The panel tab and resize graphic also have a special single-depth context menu to minimise, maximise or close a panel.

Server Communications

Inside the communications frame are one or more iframes that are used to communicate with the server. Clicking on a link or submitting a form on a panel will not normally replace information on that form directly (as a web application does). The information is sent to the server through the server iFrame. The response may or may update the calling form - typically by changing specific information, rather than replacing all the contents in a blanket update. The result is a more interactive feel than the usual web application. On a working Adept application there may be up to 3 of these iFrames:

1. Client to Server: always exists so that links and form submits can talk with the server without forcing a reload of the calling panel. Any link or button in a form with an attribute of active will be activated to talk through this iframe.
2. Recording: In debug mode it is possible to record actions as they occur for later playback, or for creation of interactive unit test code. The recording goes through a separate frame so that it can monitor but not effect normal server communications.
3. Server to Client Control: There are situations in interactive applications where the browser display needs updating based on asynchronous changes from the server. The technology is often called a pushlet since it pushes information from server back to browser. Examples are timers, counters, stock or news tickers and graphs. Once a pushlet is requested it opens a connection between browser and server through it's own iFrame. All pushlet information is passed from server to client through this connection - and passed on to their respective panels.

Process Flow

An Adept system will open with at least one menu on one full-screen panel that will act as a desktop. Some menu items will open child panels that will have an iFrame to load with HTML from a HTML template. The template is loaded with a servlet that can add additional functionality - such as filling in fields. If the panel includes an activated form, a post will go through a hidden iFrame back to the server. Responses from the server are flagged with the panel so they can be used to update panel data. A response can also include commands to update other panels, create new panels, hide panels and anything else needed to create a modern interactive application.