User Management

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.

1. Menu: Menu items can be displayed or hidden based on use groups. If the node element
2. element has a groups attribute, then only users in those groups will see this menu item.
3. 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.
4. 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.
5. 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

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

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

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

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.