Adept Development System

User Management

2007-09-03T13:21:00.000+10:00

I am using Adept Bookings as a proof-of-concept system for the Adept Development System. The first thing that became immediately obvious was that now it is time to implement user management. Authentication Adept user management provides authorisation, not full authentication. So, let's start with talking authentication. Authentication is to stop unauthorised access. It typically involves log-in and some sort of time-out so that a workstation locks if left unused. These functions are best done by the operating system. Adept supports operating system authentication by allowing you to stay logged in on any user account on any hardware. Use the optional check-box for this function. Once checked then any time you go to Adept in the future you will continue where you left off. Only your user account will have this ability - so security requirements are covered. With fast user switching (available on Windows XP/Visa, OS X and some Linux distributions), we end up with a powerful and easily shared system. As each person moves away and the screen-saver kicks in, the next user will need to switch to their account. If they have Adept running it will still be available for use - exactly where they left it. This works well in a shared front-desk situation. If you want more security, add a swipe or proximity card to the mix. Installation and maintenance are an operating system task and independent of Adept. First Start When a virgin system is created - and the installation does not create a special system - then two users/groups are created - Administrator and Everybody. Both can be logged in and neither has a password. Only Administrator can create or lock out users - or change groups. Log in as Administrator and create users for all people who will use the system. Give then access to the groups that will be named after the applications they are using. First Log-in The first time you go to Adept on a new system you will be presented with a log-in screen. If the application is single-user, choose the user you maintain and set it to stay logged in. You will not be bothered again. If more than one person use the system the the administrator will have created user names to suite. Resist working as Administrator or the user with the same name as the application unless absolutely necessary. Authorisation Once logged in the user object is attached to the session. Each user belongs to two or more groups. Various components recognise groups and change functionality accordingly.

Menu: Menu items can be displayed or hidden based on use groups. If the node element
element has a groups attribute, then only users in those groups will see this menu item.
Applications: The Desktop menu has an Application item. Valid applications are in the configuration files. Any PROPERTIES.TXT in any META-INF can have an entry named adept.application. This entry includes the name and group that can run this application. adept.application=/BookingsAdept,BookingsAdept.
Trees: have 4 attributes - displayFor, hideFor, openFor, lockFor. The first two allow a branch to be hidden or displayed. The latter two specify whether the branch can be opened if it has sub-elements.
Input: have 4 attributes - displayFor, hideFor, editFor, lockFor. The first two allow a branch to be hidden or displayed. The latter two define whether the branch can be edited or only displayed as read-only.

The Static Active Tree

2005-08-08T17:53:00.000+10:00

The reason for the unusual title is because I've created the visual tree code for Adept. The first use is in the options system. I've chosen the large-input method of tree on left and panels on right favoured by X-Windows over the panel-and-tab approach that Windows programs enjoy. It provides for a much richer selection set - but looks rather silly when there are only a few panels. The options system will be the subject of another article later (when this feature is ready).

Most of us are familiar with this form of visual tree representation. Windows Explorer and its ilk use it to display the list of folders on the left, for example. Each line is a branch or leaf. If a branch it has a + to open and view sub-branches, or - to close and hide them again.

In truth, I was surprised at how easy a visual tree was to develop using DHTML and CSS. My first version, written years ago for an online art gallery was for older browsers. This made it more complicated and less elegant than the current generation.

To create a tree, place it inside an activated FORM or SPAN element. It is an unordered list (UL) with a class of tree.

 ul class="tree">
   li>One
     ul>
       li>1.1
       li>1.2
       li>1.3
         ul>
           li>1.3.1
           li>1.3.2
           li>1.3.3
           li>1.3.4
         ul>
       li>1.4
     ul>
     li>Two
 ul>

This gives a result shown below. Clicking on the ± will expand/hide the node. In practice each node will consist of links, images or other active elements. Implementation was so remarkably easy that I have included it here in full. They style sheet, as usual is all about presentation. The only part critical to the tree is to hide inner unordered lists by default so that the tree starts closed.

When a branch is clicked on it will investigate the open attribute for the node and hide or show the underlying unordered list.

ul.tree, ul.tree ul
  {
    margin: 0px 0px 0px 16px;
    padding:0;
    font-size: small;
    color: gray;
  }
ul.tree li
  {
    list-style-image: url(/tree/no.leaf.gif);
  }
ul.tree ul
  { display:none; }
ul.tree a
  {
    text-decoration: none;
    color: black;
  }

The supporting code is a little longer, but not much. The activation system calls Tree.activate(), passing it the unordered list element that has a class of "tree". Only a single event listener is required for the whole tree as it uses the node clicked as the target to be processed. It will look for an open attribute and open any branch node that has one. The image displayed for each node is set by the activation code.

/** Called by ActiveComponent.js to activate a tree component. */
Tree.activateTree = function( ul)
  {
    System.linkStyleSheet( ul.ownerDocument, "/tree/Tree.css");
    ul.addEventListener( "click", Tree.toggleTreeEvent, false);
    Tree.activateTreeLevel( ul);
  }
  
Tree.activateTreeLevel = function( ul)
  {
    for (var li = ul.firstChild;  li;  li = li.nextSibling)
      if (li.nodeType == 1  &&  li.nodeName == "LI")
        {
          innerULs = li.getElementsByTagName( "ul");
          if (innerULs.length > 0)
            {
              /*
               * We have an inner UL, so treat li as a branch
               */
              li.ul = innerULs[0];
              Tree.activateTreeLevel( li.ul);
              li.style.cursor = "default";
              li.open = (li.getAttribute( "open") != null);
              Tree.showTree( li, li.open);
            }
          else
            {
              li.style.cursor = "default";
               li.style.listStyleImage = "url(/tree/leaf.gif)";
            }
        }
      /*
       * Work-around because style images don't work
       * without a refresh in FireFox.
       */
      ul.style.display = "none";
      ul.style.display = "block";
    }

Tree.toggleTreeEvent = function( evnt)
  {
    Tree.showTree( evnt.target, ! evnt.target.open);
  }
  
Tree.showTree = function( li, open)
  {
    if (! li.ul) return;
    if (open)
      {
         li.style.listStyleImage = "url(/tree/minus.gif)";
         li.ul.style.display = "block";
         li.open = true;
      }
    else
      {
         li.style.listStyleImage = "url(/tree/plus.gif)";
         li.ul.style.display = "none";
         li.open = false;
      }
  }

Extensions

The first obvious extension is to add keyboard control. Once the key is clicked it should gain focus and process the four arrow keys to move up and down or in and out of the tree structure. This is not important for windows-explorer-like applications (and the options system is such). After all, who uses the keyboard interface on Windows Explorer? I had to try it just then to confirm that it had one. Other applications, however, work differently. If the tree is part of a system editing system where the hands spend more time on the keyboard than on the mouse, keyboard control becomes an important time-saver.

And this brings us to the next extension. The current tree is static. The server provides an unordered list and this code displays it. What if the user wants to add, move or delete nodes? This will need to be controlled by more keystrokes (shift-arrow for moves), and to implement drag and drop functionality.

I don't need this additional functionality today, but I do have plans that will require it in the near future. When it's ready I will write another article.

Adept Progress Report - First Pass Complete

2005-07-19T20:55:00.000+10:00

So I've had a couple of months between contracts. Naturally, I've been spending quite a bit of time applying for every contract in sight, but the rest of my time has ben devoted to completing Iteration 1 of Adept. I have to say, it's looking good. It's not ready for Source Forge release yet - that won't be until the end of the year - but I've reached major milestone. I'm ready to use the result in anger.

The panelling system is complete. It's now possible to attach panels to each other or the edge of the desktop, and to create tiles as well as the panels' native drag-and-resizeable window style. Any desktop or panel can have a menu built up from multiple sources - beneath the standard File/Edit/Window/Help top-level menus. Any application running under Adept will have at least two desktops - the primary desktop and one for the specific application. As of this iteration, the primary desktop finally allows for launching of the application - and later it'll be filled with useful tools such as notes, alarms, calender, link collections, etc.

So it's time to get the ball rolling. To prove the viability of Adept I'm starting on the first commercial application that will use it - Budget Adept. Why a budget program? I've been budgeting my small business and household using a spreadsheet for the last three years, and I'm definitely a budget convert. I see the value and exactly how much I'm saving. More importantly, the way my budget system works is fundamentally different to the methods I have used in the past while using Quicken (and a brief, horrifying jaunt into MS Money). I believe I know enough now to create a kick-ass budget program.

From an Adept perspective, once this application is ready for release I can be quite confident that Adept is solid enough for use in the real world outside my office. Then I can take the time to release it on Source Forge - so you should look Budget Adept in early 2006. (nb: if you can't wait, drop me a line and I'll let you have a pre-release copy)

I don't really imagine I'll get far with Budget Adept before I'll be back to tweaking and adding much-needed features to Adept. For example, while Adept already has basic form handling, I'll need to add list handling. I'll also need to integrate date and tree-shaped reference lists. Point is, once I've implemented a working core for Budget Adept, I can start testing it while I flesh out the complete system.

The next phase will be in producing production code from Adept. This involves compiling under gcj and resolving all the issues that will arise. Then there's browser compatibility - it currently works fine under Mozilla/Firefox, and is designed to work under IE6 also, but there are sections that are so far untested in this environment. It's always more difficult to work under IE as this environment has nothing to match Venkman for debugging (that I've found, anyway).

Those are just a few of the latest highlights for Adept and Budget Adept - more as things progress.

Look and Feel - The Adept GUI Layout

2005-06-06T20:53:00.000+10:00

While Adept is an application server, it provides an interface that has more in common with a native GUI program.

The Adept system will normally open in a browser window without menu, button bar or status bar. It provides multiple windows into one or more applications running under Adept. Each of these windows run in their own panel. Panels can run in desktop mode - in which case they cover the browser window excluding a tab bar at the button - or window mode when they can be dragged or resized. The result is similar to a Windows MDI (multi-document interface) application.

A typical Adept application will have one desktop panel containing multiple window panels, providing different views, forms or data. Because a user is free to maximise a window panel to create a desktop one, this structure can be modified to suite individual tastes.

A window panel can have a resize point on the bottom left, a title tab on the top, a border and a shadow. Each feature can be turned off. In addition the title tab can be set to only become visible when the mouse curson hovers over it.

This allows the developer many visual options. By positioning panels to suit and turning off all decorations, an application interface would appear totally different to the same code where the panels could overlap, be resized or moved.

All these options can be set programatically or by the user. Once changed they are saved so that next time the program is run the same windows will display with the same decorations, at the same size and at the same location.

Each panel can have a horizontal menu and button bar associated with it. In most cases, the desktop panel will have these tools while the inner window panels provide more detailed information. There are times, however, when having an inner window panel with menu and button bar makes sense - an editor panel for instance.

The Adept GUI is created with DHTML, so the look and feel to the panels and their decorations can be completely altered by changing a style sheet and a few images. KISS is the key here.

Inside the panel, below the optional menu and button bar, is the window to the application. It will be loaded when the panel loads. While it is a browser window and can be reloaded on demand, Adept provides facilities for update without reload.

A panel close command just hides the panel so that a re-open will display it quickly without a reload (unless needed).
Buttons and links post and get through a hidden frame so that the page with these action objects does not have to reload. The server can update the display of the calling or other related window.
Adept provides many facilities to update dynamic displays using DHTML, that can be driven by server or client as the needs arise. It is possible, for example, to insert, remove or update rows in a table without redisplaying the whole page.

Servlets - Types and Uses

2005-05-19T13:26:00.000+10:00

An Action

is the most primitive servlet. It's used to give a command to the server when no response is expected - or when the response is processed externally. All servlets implement ActionInterface - defining the execute() method that's called by the connection manager. An action saves references to the request, response and parameter information blocks then calls process() - an Action inherits from this class and must implement the process() method.

The base Adept system includes one Action StopServer that, when given the correct password, will stop the server from the browser/client. The Action includes a go() method that can be used for invoking methods other than the default based on the _action parameter or a dot in the name (see above). If go() is used, the class can implement setup() and teardown methods to wrap common code around the action method called for.

CGI

is a method for Adept to run normal operating system dependant programs as CGI. A CGI program is independent. Anything output from is expected to be able to be rendered by the browser. Scripting languages such as Perl and Python have CGI libraries, but an program can generate a HTTP string and produce a valid display. If the script has an extension of cgi, the you don't need to explicitly mention the CGI servlet as in /mytest.cgi?param1=one. CGI programs of other names can be run if the servlet is explicit - /CGI?mytest.bat?param1=one. In all cases, in true CGI tradition, the output to the console is redirected to the browser.

Batch

is an extension of CGI for normal command-line programs that aren't browser aware. A batch builds up a valid HTTP stream and wraps the program output in <pre> tags so that they'll display as they would on a local terminal.

Exec

is designed for GUI applications where the browser and server are on the same machine. It will execute an operating system program then complete without waiting for interactions. With the Exec class you can create a program launcher using HTML on a web page.

A Service

encompasses the next level of sophistication over an action. It is designed to send information to the server where the responses will be JavaScript commands. It does use go() to call methods other than the default respond method. It is an abstract class, and respond() must be implemented. It contains a protected JavaScript instance for building JavaScript commands to give the browser. It has convenience methods to display a message on the status line and to pop up an alert box.

The Page

consists of a class file of the specified name in the package path and a HTML template file of the form className.template.html. First the target for all operations is set to the calling context/panel. Next, go() is called and if a non-default method is called, Page acts like any other Service. If the default is called, the template is sent, forms are activated and initialise called to continue class-specific initialisation. The JavaScript object allows scripts to be sent both before and after the HTML template. While the class is called Page, it's more often posted to the hidden service window where the HTML contains templates used to change the look and feel of an existing panel.

Processing a HTTP Request

2005-05-14T10:35:00.000+10:00

The process has been touched on in The Adept Server Model. Here I'ill document the raw and specific data.

Each request has complete ownership of their own thread until they respond again to the server.
You can turn request logs on so that each request is written to the log in full before processing.
In debug mode, no request is cached in either the browser or the server, so you can change files and see the results immediately.
If the request URL ends in a slash (/), the default actions are explored immediately; otherwise an action is looked for as:
- If the file type is registered against a servlet by the server, that servlet is run. The standard system registeres js for Javascript and cgi for CGI; or
- If the file type is registed by the browser (as part of the request as a mime type) the file is sent directly to the browser for processing. Examples of these are html, gif and jpg; or
- The request of for a servlet. If the request includes a stop (.), it is considered a defined method in the servlet class, otherwise, the default execute() method is called. Typically an application will use the default execute() for loading the page and defined methods as responses to links and form posts. The servlet method to call can optionally be set with an _action parameter instead.
If no action is found so far the default actions are explored, treating the URL as a directory or path.
- A servlet called Index in the package specified by the path. The execute() method is called.
- A script or program called index.cgi. For unix based systems it will be marked executable. For Windows, cgi needs to be associated with an interpreter.
- A static html document called index.html
- A static html document called index.htm

The Adept Server Model

2005-05-05T09:39:00.000+10:00

The Adept Development System has as its goal the use of corporate skills and technology to produce shrink-wrap software. One of the core design decisions was to use a DHTML-enabled browser as the GUI. This means that the Adept server is a web/application server in the same family as Tomcat. There are differences: Adept has been developed from the ground up to serve a DHTML client, not a Java Server Pages intermediate.

The Server

At the core there is a Server class that runs in its own thread until it's asked to be closed. The main thread normally just waits for the server thread to complete. The separate threading is mostly a convenience for testing, where the test methods want to spawn a server and send it stuff to test. So the server class has the simple function of waiting for client connections, then spawning off a new Connection object to service them. Some servers attempt to minimise the expense of starting a new thread for each connection by pooling connections, but I considered this a case of the benefit not being enough to cover the risks. Modern HTTP 1.1 protocols keep the same connection for use for as long as they can - typically minutes but often for much longer. And on the other side of the coin, starting a clean thread for each new connection ensures that data won't accidentally survive to be used by another thread. This model is inherently multi-user.

The Connection

Each connection also runs in its own thread. This allows the same server to service multiple connections from the same or different clients. As a standard, most browsers make 2 concurrent connections to the server. A connection survives until the client closes the socket or until it is unused for the timeout period of 5 minutes. The browser will at times close the connection and ask for a fresh one using internal rules of it's own.

The Request

The connection then waits for a request from the client. The first thing a request does is attempt to associate a session. The URL of the request is then parsed. If the command ends in slash(/), the default action is looked for. If a normal action cannot be associated a slash is added and the default action attempted again.

For an action, default or no, the request will first look at the file type of the request - being everything before the ? or end of request back to the last full stop. If a servlet is registered against a file type (as with .js), it is used. Otherwise, if it's one that the client has registered it's sent as-is to the browser. If neither of these occur, the request looks for a Java class that extends from ActionInterface. If all else fails, it's sent back to the client to see if it can be rendered as-is.

The Session

A request looks for a specific browser cookie for the session ID. If there is no cookie a new one is created to send as part of the response. In the disconnected client/server environment, this is the way we keep data for the session - by associating it with a unique cookie. By default this cookie is called AdeptSession - although it can be changed by setting a property called session.cookie.

The session name can be either an automatically generated name for anonymous connections, or the user name once the user has logged in. The anonymous name is a persistent cookie so that related data is kept permanently. If a user logs in this cookie is overridden by a browser session cookie that will be lost when the browser is closed or the user logs off. It's possible to make this cookie persistent for secure machines.

Default Actions

If default actions are given a path only, the server will look for a default action to run - being either a servlet called Index, an external program called index.cgi, or html documents called index.html or index.htm. In general it's better to specify the full action rather than ask the system to search for it.

Registered Servlets

Normally any file with an extension is sent to the browser/client for rendering. This be anything from documents to text files, images, style sheets or JavaScript. Occassionally it will be useful for server classes to know about or filter the information. Currently the only existing example within adept is in loading JavaScript classes. They are registered against a servlet called LoadJavaScript that adds a call to a JavaScript._afterLoad(), which Adept uses to sequence loads and initialisation of Javascript.

Each class is registered in server code using LoadJavaScript.Server.register(), giving it the file extension and a class with an ActionInterface to do the work.

Running a Servlet

A servlet is a class with a com.marringtons.adept.action.ActionInterface interface. Its execute method is called wrapped in a transaction. Any exception will cause a rollback, while a clean return will trigger a commit.

The JavaScript Model

2005-04-29T12:34:00.000+10:00

In all the web services projects I have been involved with, JavaScript has been used as a separate tool to make the GUI prettier. In some cases it has done essential validation and form processing - although most architects object to having any functional dependence on JavaScript. Frameworks, for example Sofia, may generate JavaScript to be sent as part of a page.

Adept is completely different. It has been designed to use the browser to create a system with the speed and interactivity of a native application. To do that it makes heavy use of DHTML - and JavaScript is a core component of DHTML. In fact, JavaScript is the D which stands for Dynamic.

Adept changes the architecture also. In a traditional web system the browser is merely a renderer, with everything occuring on the server side. In contrast, using Adept, two layers of the GUI tier run on the browser - and are designed and documented with this clarity in mind. JavaScript becomes part of the design, not just an add-on that is tolerated when necessary.

So, how is this accomplished? When Adept loads, it includes an invisible iFrame that's used to post or send information to the server. Both the invisible iFrame and visible panels work the same way. They're filled by the response to a servlet call. The servlet will set up the DHTML environment (ensuring that any required JavaScript is loaded), pass a HTML template of the same name, then generate any JavaScript required to activate the DHTML.

In the case of the communications frame the HTML portion is usually empty, but it can contain patterns that are loaded into the calling visible frame by JavaScript System methods. JavaScript specific to the servlet will fill in dynamic content for a panel, expand lists, open new panels or generally change the UI in some way.

For the visible panels, the HTML is that which is seen. The default JavaScript activates it so that form actions and links post to the communications frame. Then Servlet specific JavaScript is run to do whatever dynamic work needs to be done. The idea of the sample template is that it works stand-alone: designers can create it, add sample data, show it to the customer and generally treat it as their own. They can continue to do so even after it is integrated into the system. The developer activates it by adding IDs and additional properties to elements, but that's all. The system will remove the sample data during the load and turn the static page into something dynamic. Additionally, the page designer can continue to maintain the pages as long as she leaves the additional properties as-is. I consider this as far better than current practice where the developer turns design HTML into JSP or ASP, while the GUI designer loses access.

The JavaScript model uses objects to provide separate namespaces, with the object name matching the file name in classic Java fashion. Each of these namespace classes has a Java mirror of the same name, as does each public method inside the class. Apart from allowing the server to call these methods, the Java also provides full Javadoc documentation.

All the Javascript is loaded into the top Adept frame and made available to all panels as part of the initialisation process. The initialisation ensures that new JavaScript files are loaded before the code that needs them is executed. The effect is to provide a load-on-demand infrastructure similar to that used by Java.

Check out the Javadoc provided by the Adept system for examples of JavaScript usage from both the server and the client.

The Adept Client Model

2005-04-15T15:42:00.000+10:00

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:

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

Session and Conversation Data

2005-04-01T15:15:00.000+10:00

This article is an extension of Data Lifetimes in my Software Development blog.

What is Session Data

Session data is data that lives as long as the session is active. A session is active from the moment the browser first connects or a user logs in until the session times out - typically 20 minutes of inactivity after the user leaves the site or closes the browser.

What is Conversation Data

Conversation data is much shorter lived. It can exist from the moment a browser makes a get or post request to the server and goes out of scope as soon as the browser receives a response from the server. Conversation data is mostly used to return information, validation and error messages to the browser for display.

How Session Data is kept in Adept

Class com.marringtons.util.Session contains a static private com.marringtons.util.Cache instance that will hold session data and release it if not used for a specific interval (defaulting to 20 minutes). If a browser has never connected before, create() is called to generate a unique key. This is saved in a permanent cookie on the browser called "AdeptSession". This key is used to retrieve a session or create a new one at the start of each conversation. With this method the same session will be used by all instances of the same browser for the user currently logged in at the OS level. Closing the browser and reopening (before the timeout) will continue to use the same session. Using the same browser after the session timeout will still retrieve persistent session data.

This all changes if the user logs into the Adept system. A session-only cookie of the same name ("AdeptSession") is created with the user's name. This is used to retrieve session information - and isn't a security risk since the user is authenticated against the session at the start of each conversation.

In either case, because the thread is named for the session, a static getInstance() without parameters can be used to retrieve the session data dictionary.

Session session = Session.getInstance();

How Conversation Data is kept in Adept

Conversation data is kept in a much simpler static private Map, with the conversation keyed on the thread name. Since a conversation is sequential, it will use the same thread from beginning to end.

Manipulating Session Data

Retrieving the object from the session depends on it's scope and type. An object can have a scope of:

Class scope. Use classScope();
Package scope. Use packageScope();
Global scope. Use globalScope();

Use the above methods to create a static final field in the calling class and use that to access session level data.

Objects can be one of three types also:

Transient entries: are lost when the session closes.
Closeable entries: have a close method that is called when the session goes out of scope. Data class implements com.marringtons.util.Closeable.
Persistent entries: are saved on disk and retrieved the next time the session is activated (a user logs in). Set by final parameter in scope creator method.

Because session data can have type, scope, persistence and closeability, a Session.Key is created to contain it. For efficiency, this should be a static final field in the class that's making use of it.

Manipulating Conversation Data

Because a conversation is relatively short-lived, the com.marringtons.util.ThreadData class is much simpler. There are getters that create a new instance if needed, those that provide a default and those that use the class name as key name (for local scope). There is also, of course, a matching setter - although it's rarely used since most instances are created automatically using a default constructor.

Session Data: A Real-World Example

private static final Session.Key recordingSessionKey
  = Session.classScope( Tape.class, "taping",
    null, Session.transientLifetime);

private static final Session.Key storageSessionKey
  = Session.classScope( Tape.class, "tape",
    null, Session.persistentLifetime);

public static Tape load( Session session)
  { return (Tape) session.get( recordingSessionKey); }

public static Tape create( Request request)
  {
    Tape tape = load( request);
    if (tape == null)
      tape = new Tape();
    else
      tape.commands.clear();
    tape.startPage
        = request.getParameter( "startPage");
    request.session.put( recordingSessionKey, tape);
    return tape;
  }

Conversation Data: A Real-World Example

/**
 * @return Messages associated with this thread.
 * Usually used as error messages to be displayed
 * in response to a browser request.
 */
static public Messages getThreadInstance()
  {
    return (Messages) ThreadData.get( className, 
        Messages.class);
  }

The Browser as a Client

2005-03-21T09:02:00.000+10:00

For all of my 25 year career I have wanted to develop platform independant shrink-wrap software. Technically this has been possible for some years now by writing in Java, Perl or Python - with the latter two using TCL to provide a GUI. I resisted this approach for a number of years because:

For less than practical reasons I was not happy with releasing interpreted code.
It's inconvenient for the end-user. None of the interpreters or virtual machines come stock with the operating systems, so the user has to locate these themselves.
Java is the only language that has IDEs to help lay out visual components.
Most users consider the GUIs produced for Java, Perl or Python software to be a little strange, simply because they aren't native.

As you've probably gathered, one of my most consistent problems has been with the GUI. Admittedly Swing has improved out-of-sight and Eclipse is providing a competitive cross-platform system. Long before either of these alternatives became available I had decided to use a DHTML browser as the front end for the Adept Software Development system. This is something I stand by, too - a DHTML browser of some sort is native to every operating system, is hardware independent, and is an interface that most users know like the back of their mousing hand.

Advantages of The Browser and GUI

There are plenty of powerful tools for creating outstanding and variable user interfaces. Any recent HTML editor, in fact. Web designers are entirely familiar with the necessary tools and can provide quality interfaces far beyond those that require a developer to create..
Familiar user experience - even a user who might feel totally lost within the Java Virtual Machine is likely to be able to handle their browser of choice.
Full access to the rich media the browser provides natively - including (but not limited to) video, images, PDF, Javascript, Macromedia Flash/Shockwave and Java applets.
The GUI is only loosely coupled with the server, so changes to the visuals of the interface are non-destructive and simple - often accomplished by simple changes in the style sheet.
DHTML techniques allow the designer page to be used without change. This means that the designer can update pages without a developer having to go back and translate it into production code again.
The web server design is inherently multi-user. This means you can run applications at home, access them at work, or provide the tools and data to your workgroup.

Disadvantages of The Browser and GUI

The browser is great for multi-media and form based work. It is not as suitable for complex interactive programs similar to word processors or spreadsheets. Of course there are many good plugins (Java Applets or Native Active-X components) that will fill many of these types of tasks and still work well with Adept.
Many believe that HTML, DHTML, XHTML and XML do not provide the best in GUI design. For those with this viewpoint, Adept is a less useful tool.

Requirements

2005-03-15T15:33:00.000+10:00

I have developed the Adept Development system for my own learning and for my own used. I set the following goals:

Make no compromises. I develop the software to my best ability without compromising quality. I've had my fill of working on projects where time and money overrule the principle need for good design and code.
Must be fully documented. I provide ongoing full documentation as part of the code - line by line - and keep it up during updates and changes.
Full Unit Testing at all levels. Unit testing is a concept I've embraced, and I want to see how it fairs when fully implemented.
Use Browser/DHTML as the front end to make full use of the talents of the modern GUI designer. It is popular to criticise the browser as a client, but I believe the advantages outweigh the problems.
Must be inherently multi-user. The application server/browser framework allows for more than one user. I see no reason why this shouldn't be implemented to provide the same conveniences to the single user.
Must be cross-platform. It has always been part of my vision to provide the same software on Windows, Mac and Unix/Linux, without having to spend costly months on ports.
Implement separation between the GUI and back-end so that a HTML designer can continue to work on production pages without referring to development staff.
Follow correct architectural principals to divide application development up horizontally (separate tiers) and vertically (clear functionality packages).
Be able to be compiled by a native compiler such as GCJ to provide shrink-wrapped packages of software for each platform.
Not to rely on server based database systems such as Postgres - although the users of the system should be free to use these if that is their desire.
To work on all modern DHTML compatible browsers - Microsoft and Mozilla/Netscape based, as well as on OSX browsers like Safari.
To provide clear and useful session management - including the simple retrieval of session and conversation data without having to explicitly pass them through the tiers.
To provide a system that can be easily used by corporate developers - with the tools, packages and techniques that are familiar to them - to create shrink-wrapped software packaged to give away or sell.

Introduction

2005-03-10T09:59:00.001+10:00

My name is Paul Marrington, software developer. Well, just Paul Marrington, actually. The software development part, as you might have imagined, is what I do. Before you join the other 99% of visitors to any given web-page, why not take a moment to hear a story that has a good chance of hitting close to home.

I joined the software industry in its infancy, and by the early 80's I was spending my time exclusively developing software for myself and my customers. I was among those who saw the merits of micro-computers before they became mainstream, and so the PC was my bread and butter for many years. Shareware was the word of the decade, and each person owned themselves.

But - and this is the part that might sound familiar - a family and the necessities of life forced me to realise that the only customers who could afford to consistently support developers in their trade were the corporations, and so I joined the queue and was contracted out. For the last six or seven years my primary source of income has been working as an architect and development manager for corporate client/server systems - the mainframe'd masses - and it scares me how easily I joined their ranks, and how quickly my skillset began to be molded exclusively fit the Information Systems model.

However, working as a corporate development manager I came in contact with many developers who were highly interested in application development, and I came to see that a great deal of client/server architects would be developing shareware and freeware for themselves, if they could use the same techniques and tools that they were used to.

I've also watched designers develop HTML pages for the business to sign off and give to developers to be converted into xSP (JSP, ASP, PHP, etc) for implementation. Not only does that mean developers are wasting time in the conversion but more importantly, the designer cannot easily change the interface as the customer's needs change. I like the idea of the web page signed off by the client going into production with little or no change. That way the GUI designer can make visual changes without interference from development.

So, wanting to try my hand at application development again, and hoping to eventually provide the same opportunity to my colleagues, I decided to create a system for enterprise developers to be able to create shrink-wrap systems. Adept (Application Development - Enterprise to Personal Transformation) was born. I have divided my development efforts into two source trees. There is a support library in com.marringtons.library, while the Adept specific code is in com.marringtons.adept. See Adept Open Source Library for the blog on the support library and Adept Software Development for general discussions on software development.

The Adept Development System is specifically designed to leverage developer tools, libraries and skills to provide shrink-wrapped products. Put simply, if you want to use the skills, tools, etc that you use in your corporate job to create software to give or sell to friends and clients, then Adept will provide you with what you need. That still leaves the question: so what is Adept, then? The simple answer is a personal web server designed to fully utilise DHTML to provide a truly integrated client/server system using a browser for the GUI.

Benefits of the Adept Approach

Well known GUI and tools using the modern browser of the user's choice.
Full access to the rich media the browser provides natively - including (but not limited to) video, images, PDF, Javascript, Macromedia Flash/Shockwave and Java applets.
GUI is loosely coupled with the server - allowing easy change of look and feel - often by changing the style sheet.
HTML Web designers are totally familiar with the tools and can provide a depth and quality of interface far above that of any GUI that is created mostly by a developer.
DHTML techniques allow the designer page to be used without change. This means that the designer can update pages without a developer having to go back and translate it into production code again.
The web server design is inherently multi-user. This means you can run applications at home, access them at work or provide the tools and data to your workgroup.
Client code can be written in JavaScript, Flash, VB or even Perl if you are willing to install the Perl plugin and use IE. You can also use activeX, Java applets or other mechanisms to provide a rich client. The basic system requires only Javascript to be enabled - and Javascript is available natively on all platforms.
Adept Server code is written in Java and natively compiled using GCJ. This allows additional server code to be written in Java, Groovey, Python (using Jython), Javascript or any of the miriad of other languages supported by the Java platform. See this page for examples.
Java has a rich source of libraries for every occasion from many sources. There are libraries to serve MPEG, render PDF, process XML and just about any other task you can imagine. Many of them are open source.
Adept provides a server push technology to allow the server to update the client display when the server finds a reason.

Limitations in the Adept Approach

The browser, and hence Adept is great for multi-media and form based work. It is not as suitable for complex interactive programs similar to word processors or spreadsheets.
Many believe that HTML, DHTML, XHTML and XML do not provide the best in GUI design. For those with this viewpoint, Adept is a less useful tool.