The JavaScript Model

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.