Section V: Case Studies
Case Study: Mortgage
Introduction
The Mortgage application which is outlined as part of this case study is taken from the tutorial which is available for download from the Aria project on the sourceforge site. The intention of the tutorial is the make the developer familiar with development elements of the Aria/Aria framework. The development of the application is split over several different tutorials which gives the developer a fully working version of the application at the end of each step.
In this case study we are going to examine the elements which make up the application in each tutorial. In summary the tutorials are as follows
Introduction
This step shows how to set up the basic structure of a Aria application and what files and libraries need to be included. It creates some simple pages and shows how to navigate the application. It shows how to add page events, validations, data bindings and dynamic bindings. The application is completely localized in the final step and the model is used to output captured data.
Advanced
This step builds upon the introductory tutorial and provides the user with a more generic navigation which allows new pages to be added very easily. It also shows how library functions can be used to help with the navigation. Custom validations are created which are loaded via a custom ValidationFactory. Framesets are customised and component registration is used to develop and load custom components. Custom dialogs are created which report on the types of errors being generated. Model data is saved from and restored to the model showing how easy it is to create applications where projects can be created and opened.
Aria Editor
This tutorial really replicates what was done in the first step except that the development is carried out with the help of the Aria Editor editor.
Aria
In introducing Aria the application is makes use of the routes which are available in the Aria library. This allows the developer to create applications which can easily connect to a servlet server making use of authentication and session management services. Data can be cached on the client and the application can be used to work with them offline and then synchronise with the server. Custom ServiceProxy classes are created which are used in transforming mode data.
Introduction tutorial
This tutorial begins by showing the project structure for a typical Aria application as shown in the diagram below.
 |
The run.bat file contains the text below.
The run.bat file
The application is made up of frames which are defined in the frames.xml file as shown below.
The frames.xml file
Navigation
The project navigation was handled by the navPanel page in the navPanel frame. In order to do this two images where added to the navPanel page as shown below
navPanel.xml page
Two images are added and each has a MouseHandler event added to them. The nextPage and prevPage functions are defined in the NavPanel class as follows.
The NavPanel class
This navigation depended on the presence of the next attribute in the main content page
Bindings
Dynamic binding was used to address different nodes within the data model. On the personal page the binding are declared as follows.
The bindings on the personal page
These bindings depend on the callback function getCustomerID in the Personal class as follows.
The callback function in the Personal page
This class takes care of tracking which customer is being currently processed allowing numerous customers to be added to the model in their own specific nodes.
Saving the model
The model data was then saved within the Finish class pageActivated function.
The Finish class
This provided us with the following output.
Model data saved from the application
Localization
The entire application was localized through the use of language specific resource bundles. For example the personal page was localized simply by changing the content attributes for the components.
The localized personal page
The resources were entered into two resource bundles for English and French.
Extract from en.properties
And the French translation:
Extract from fr.properties
A combo box was then placed on the welcome page which allowed the user to switch language. The selection of a language invoked the following code in the Welcome class.
Language switching code
This completed the introductory tutorial and the resulting application can be seen below
 |
Advanced Tutorial
This tutorial uses the application created in the introductory tutorial and begins by adding custom validations and a custom validation factory. The custom validation calls a function within the Page and returns the result of it. The custom validation is shown below.
The custom FunctionValidation factory
In order to use this validation a custom validation factory need to be created as shown below.
The custom ValidationFactory class
The getValidation function checks to see if the type being created is function . If it is it creates a new instance of the FunctionValidation class and returns it. If it isn't the super getValidation function is called in order to retrieve the validation.
In order for Aria to use this validation factory the following line needed to be added to the startup properties.
Startup property for the custom validation factory
Now the welcome page was amended to use the new validation.
XML declaration for the function validation
And the welcome class was amended to include the checkCreateSetup function
The checkCreateSetup function
This function checks to see that at least one of the radio buttons on the welcome page has been selected. If everything is OK then LEVEL_IGNORE is returned otherwise LEVEL_ERROR is returned and the error message is displayed.
Bindings
The tutorial now goes on to show how the data model can be reopened once saved. This required the use of a custom data binding which was added to a list component on the welcome page.
Binding to the list component on the welcome page
Now the saved files needed to be listed when the pageCreated function was called.
Loading files into the model
Child nodes containing the filenames are added to the applications model node and the updateBindings function of the page is called so that the list will refresh. Now the selected file could be opened and restored into the model as follows.
Opening and restoring the model state
The restoreState function is really of most importance here. It initialises the aria_state and mortapp nodes. It then loads the model into both of these. Again, updateBindings is called so as to refresh the state of the radio buttons on the welcome page.
The list can be seen on the welcome page below.
 |
Navigation
The navigation of the applicaton was improved by making use of the library functions which are part of Aria. To do this the navPanel page was changed to reference functions in the Navigator class as follows.
The amended MouseHandler events in the navPanel page
The Navigator page was created as a Singleton instance class and included the static functions next and previous . The pages to be included in the navigation were defined in a new navigation dataset as follows.
The navigation.xml file
The Navigator class took care of keeping track of where the application was in the navigation sequence and of repeating the relevant pages where for the amount of customers being processed. Now each of the pages in the navigation could use the same class to return the correct customer id.
The generic CustomerPage class
With this mechanism the navigation was greatly simplified and pages could be added very easily by referencing them in the navigation file. The amount of customers which could be process is now endless and all taken care of by the very simple Navigation class.
 |
Framesets and component registration
The framesets in were amended to include a status frame to show the user exactly where they were in the application navigation. A new frame declaration was added to the frames.xml file as follows.
The new declaration in frames.xml
This frame was made invisible on the welcome page and visible on subsequent pages. It's visibilty was controlled by the Navigation class.
A custom component was then created which listed all of the pages to be processed and highlighted the current one. It was declared in the components.xml file as follows.
The components.xml file with the declaration for NavViewer
Now a NavViewer instance was added to the navPanel page as follows.
The AppStatus.xml file
Now the NavViewer class could take care of displaying navigation information as below.
 |
Dialogs
A custom dialog was introduced to display errors and warnings with different icons. This new dialog also allowed the user to proceed if only warnings were generated. The exception handler needed to be amended to store the errors and warnings in their own respective vector objects as below.
The ExceptionHandler class
The getDialogResult function creates the new ErrorMessage dialog and passes in the two vectors. The return value determines whether the page can proceed or not depending on what button the user clicked.
In the ErrorMessage class the relevant return value is set when one of the buttons is clicked as follows.
The ErrorMessage class
Case Study: Wizards
- Wizard application
Introduction
This wizard application which will be examined in this section is for generating product selection applications for SMEs. It is a fully functional application and is in use in production environments by some of Formaria's clients. It's intended audience is small to medium companies who wish to manage their product listings and to make those products available within a simple and easy to use application. The typical user would not be particularly technical and with that in mind spreadsheets were chosen as the preferred format for storing product information. The wizard is only the first step in creating the application for the end user and can be used to setup and manage any number of projects.
This application makes use of many of the features of Aria including page navigation, framesets, component registration, localization, validations, the synth look and feel and data binding amongst others.
 |
Framesets and pages
The application consists of a Aria frameset which contains four different target areas. The title frame and navigation frame both remain in the same position with the same content throughout the lifetime of the application. A status frame on the left is initially hidden and is then shown when the user decides on a wizard route. The main content frame takes up the full width of the application when it is first started and contains the WelcomePage Page. Once the status frame appears the width of the main content page is the width of the application less the width of the status frame. The frameset file is defined below.
frames.xml
From the welcome page, it is possible to select one of four radio buttons which will determine the route through the wizard.
The four radio buttons and their declared events
The XML shows the four declarations for each of the radio buttons. The application is completely localized so the content attribute is set to the key for the current resource bundle. The four event declarations are all setup to call the same method showInfo which is shown below. There is also a declaration for a label which will show information for each of the selections and, again, this component uses the current language resource bundle to populate its text. So now the information label needs to be populated depending on the selected radio button.
The Welcome class
The pageCreated method obtains references to the components which will be used in this operation and the showInfo function sets the translated text in the label for the selected radio button. This application uses a specialized Translator class which will be explained further on.
The NavPanel class is the navigation Page which was declared last in the frames.xml file above. The setNavPath call sets the navigation path which needs to be taken for the selected radio button and that will be looked at next.
Navigation
The application consists of multiple pages and navigation between pages is provided by a common class. In the screenshot below the page navigation is initiated by the buttons at the bottom right of the page.
 |
The NavPanel class controls the navigation of the wizard and is shown below.
The NavPanel class
The pages of this application are using a custom BasePage class which is derived from the Page. The reasons for doing this are irrelevant to this discussion. The setNavPath function which is called from the Welcome Page can be seen. This function assigns one of four NavigationManager instances to the currentNavigator variable. Each of the NavigationManagers accepts the next and previous buttons as contructor arguments along with the path to be followed. This allows the NavigationManagers to control the enabled or visible state of the buttons depending on where the current page of the application.
The navigation paths should be explained now. This is the path into some predefined nodes in the datamodel which can be seen in the wizardpages.xml file below. This page needs to be referenced from the datasource file as referred to by the ModelData startup property.
wizardpages.xml
Now the NavigationManager can take care of displaying the correct page depending on whether the next or previous button was clicked.
NavigationManager class
The constructor obtains a reference to the model node specified by the path parameter. This node contains all of the child nodes which define the pages for this wizard route. The constructor also obtains a reference to the wizardstatus page which is declared second in the frames.xml file. and sets its width to zero and also makes it invisible.
The showNextPage function first checks to see if the currentPage is null. If it is null it retrieves the name of the first page node in the navMdl and passes the navMdl node to the WizardStatus page. It then checks the currentpage for validations and if the validations pass the previous button is set to visible and the next page in the route is displayed. If the page displayed is the last page in the route the next button is made invisible.
The showPage function takes care is displaying the current page, making the WizardStatus page visible and passing the current node to the WizardStatus page.
The showHomePage function simply resets the variables and sets the appropriate visibility for the navigation buttons.
The WizardStatus page can now be looked at.
The WizardStatus class
The setNavModel function as referred to from the NavigationManager class can be seen taking the path node as a parameter. The setCurrentItem function stores the index of the current page in the path in a class variable. The paint function then simply iterates all of the page nodes in the navigation model and outputs the translated description of the page at intervals of twenty pixels. When the current node is reached the color of the text is changed to indicate the progress of the wizard.
One final scenario needs to be mentioned before leaving this topic. The WizardNavigator as defined in the NavPanel class is derived from the NavigationManager class and needs to do some specialized navigation. This navigation class overloads some of the NavigationManager functions in order to repeat specific pages in the navigation path. There is little need to go into the specifics of that navigation here but it's worth noting to show how custom NavigationManagers can be created.
Component Registration
There are several custom components included in the wizard application each designed to carry out a specific task. This section will look at a single component, the FileLocater, which can be seen in the screenshot above. There are two of these components on the first screen on the main navigation path to specify the project location and the icon path.
FileLocator constructor, setAttribute and actionPerformed methods
The constructor sets the layout of the panel to null. It then constructs a new StyleFactory which will use the org.formaria.swing widget set to construct it's components. The factory is then used to create the label, text box and the locate button. An action listener is added to the button. The setAttribute function as defined in the AttribedComponent interface is called from the AriaBuilder when an unknown component attribute is found. The attributes being looked for by the component are content, promptWidth, dataStyle and style. Each of these properties are set using the component functions. It can be seen how the StyleFactory can apply a style to a component with the simple applyStyle call.
The actionPerformed function shows a JFileChooser being created with it's default path set to the text of the text component. If a new path is selected by the user the text component is once more set.
The remainder of the component can now be completed as below.
Remainder of the FileLocater class
The doLayout function sets the location of the text and button components relative to the width of the text component and sets the panel to be transparent.
This component can now be declared in a component registration file as shown below.
components.xml
The following startup properties need to be set. The RegisteredComponentFactory will assume a filename of components.xml
startup properties
The custom component is now ready to be used within the Aria pages. This can now be done very simply by creating an element whose name corresponds to the definition of the component in the components.xml file.
ProjectInit XML page declaration
The location, dimension and name attributes are used as usual and the custom attributes as expected by the setAttribute function can be seen. This example gives an impression of how the StyleManager and styles in general can be used to customize the application in general.
Validations
This application requires the use of custom validations which go beyond the abilities of the basic validations built into the Aria core libraries. This requires the use of a custom validation factory which can be specified in the startup properties file as below.
Specifying the custom validation factory
The custom validation factory is shown below.
The ValidationFactory class
This custom ValidationFactory class is aware of three types of custom validations, integer , number and function . If the validation being created is none of these then the super getValidation function is called in order to create the validation and is returned. Two of the custom validations are shown below. The first:
The NumberValidation class
And the second:
The FunctionValidation class
Both classes extend the BaseValidator class and overload the validate method. The NumberValidation class simply attempts to parse the component text and if that fails the errorLevel variable of the super class is set and an exception is thrown. The FunctionValidation class overloads the setup function and retrieves the name of the method which needs to be called in order to carry out the validation.
The validations need to be declared in the validations.xml file some of which are shown below.
Validations.xml
And the validation rules themselves are as follows:
The validations defined in a page
The rate validation checks that the text entered into the taxEdit text component is numeric. The overwriteFile function calls the fileExists function in the Page as shown below.
fileExists function
The fileExists function checks for the existence of a named file and if exists the BaseValidator LEVEL_WARNING is returned in an Integer object. If it does not exist the LEVEL_IGNORE value is returned.
One of the functions of the BasePage class is to set a custom ExceptionHandler for each of the pages as shown below.
BasePage constructor
The custom exception handler follows. The ExceptionHandler class
The accumulateMessages function is called when the validations for a page begins and is passed true in the start parameter. This value is recorded in the pageValidation variable. The handleException function is called whenever a validation triggers a problem and depending on value returned from the getValue function of the Validator object the validation message is added to the appropriate Vector. When all of the validations are finished the accumulateMessages function is called once more and this time the start parameter is false . In this case an Dialog ErrorMessage is created in two possible ways. If there are errors the messages will be displayed with only a close button. If there are only warnings generated then the dialog will give the option of cancelling or continuing, disregarding the warnings. This functionality can be seen in the value returned from the showDialog function. This will be explored in more detail in the section on dialogs.
The custom FileLocater component needs to have several validations applied to it as shown below.
The FileLocator validations
These validations are declared in the validations file as below.
The validations.xml declarations
Data binding
The data bindings for the wizard application are on the whole pretty straightforward and there are some which deserve particular attention.
The projectinit page
The last four bindings are straightforward text bindings and are bound to text components. The first two bindings are bould to the custom FileLocator components created earlier. The type attribute specifies the use of a custom binding and the class attribute provides the name of the class which will carry out the binding. The FileLoaderBinding is shown below.
FileLoaderBinding class
The custom binding extends the TextBinding class and implements the setup function. The passed component is cast to a FileLocater component and the text component is retrieved from it.
The wizard allows the user to create applications with whatever languages they require. This is done through the languages page on the main wizard path.
 |
The master list component contains a list of all of the languages which are available from the wizard. The selected languages list contains a list of languages which have been selected to date. The master list is populated from a predefined set of languages defined in a datasets file as shown below.
languages.xml
This datasets definition show how the model can be used to store much more than just ids and values for a node. In the languageList node each language node has information about the localized language name the language code and whether the language relies on Unicode.
In the LanguagePage class the master list is populated in the code below.
Some of the LanguagePage class
The pageCreated method shows references being obtained to the page components which will be used in the class. New LanguageModel classes are created which are used as models for each of the lists. Taking the masterListModel , the populateMasterLangs function iterates all of the languages in the languagelist dataset and adds those elements whose include attribute is set to false . The converse is done for the listModel within the populateDefaultLangs function. This means that English will appear by default in the selected languages list when the page first appears. The updateLists function needs to be called whenever the list data changes so as to render the changes correctly. The LanguageModel class follows.
The LanguageModel class
The LanguageModel class implements the ListModel interface and as such needs to implement the required methods such as addElement and removeElement . This class is now effectively acting as a wrapper for the language models and makes it easy to move the model nodes around. This class also takes care of the default language and uses the Translator object to translate the language names to the current application language.
Localization
The application has been completely translated into Simplified Chinese and required some specific techniques to take account of the Unicode characters needed to render the language correctly. The results of that localization can be seen below.
 |
The default language for the wizard is English and that is specified in the startup properties as follows.
The language startup property
This means that the text for the language will be stored in a file called en.properies some of which is shown below. For each page in the application which is to be localized automatically by Aria the resource attribute needs to be set in the page XML.
The Page resource attribute
Section of the en.properties file
This is a typical resource file for a Java application.
The language list on the welcome page is populated from the wizardlanguages dataset declared in the languages.xml file which was shown in the previous section.
Some of the welcome.xml page
The langlist combobox is bound to the wizardlanguages node of the data model and will appear with a list of its children from which the user can select. There are two events attached to the language list changeClicked and changeLanguage and these are shown below.
Some of the WelcomePage class
The changeClicked boolean variable is set to true only when the user clicks on the languages combobox. This ensures that the code in the changeLanguage function is not executed as the list in populated by the binding. If the variable is true and the user selects a new language then the changeLanguage code is invoked. The selected language is obtained from the list and the corresponding language node is retrieved from the model. The code and encoding attributes are then retrieved from the language node. The Language startup parameter is then set for the application and the Translator is reset to use language encoding or not. Now the page manager is reset and the startup pages are reloaded into their respective target frames.
At this point its worth looking at the Translator object and how it manages the necessary fonts.
The Translator Singleton class
The Translator is a singleton class. The call to the reset function with the useUTF parameter informs it whether or not the application is running with a language which requires Unicode encoding. If so the NSimSun font is returned from the getDefaultFont function. This font could just as easily be parameterized. Now each of the StyleFactory in each of the Pages needs to make use of the Translator class in order to construct its components with the correct font so a new StyleManager class is introduced which extends the basic StyleManager class as shown below.
The StyleManager class
The custom StyleManager class overloads the two getFont functions of the base class and checks the Translator object to see if Unicode is being used. If it is then the Translator's default font is used to construct a new font with the same style and size as specified in the styles file. It's now simply a matter of telling the Aria to use this style manager which is done through the startup properties as follows.
The DefaultStyleManager startup property
The Synth Look & Feel
The look and feel of the application which can be see from the screenshots in the preceding sections is achieved through use of synth. This look and feel is only available since JDK 1.5
In order to specify the use of the synth look and feel some startup parameters needs to be set as follows.
Synth look and feel startup properties
In order to use the look and feel for panels a painter attribute needs to be specified as follows. Specifying the synth logo painter for panels
The aria.synth file needs to be available on the classpath and in this case was placed in the resources folder. The aria.synth file specifies component borders and offsets and also refers to images which it uses to render the components. For example it refers to the following two images to render the buttons. The orange version is for mouse over events giving a very interactive application.
 |
Case Study: Product Selection
- Product selection
Building CoolSelector with Aria
CoolSelector is a web-based tool for designing cold-room configurations. It was designed and built for Danfoss Refrigeration and Air Conditioning Controls group to allow their consultants, wholesalers and installers to select and configure all the components and controls needed to meet the cold-room requirements of their customers.
Originally, this sophisticated internet application was designed and coded using a mix of Microsoft tools (ASPs, COM, HTML and JavaScript). Later, we rebuilt the application using Formaria's Aria, resulting in a more streamlined tool with faster response times.
Background
Danfoss A/S, the leading supplier of Air Conditioning and Refrigeration components and controls, asked Formaria to develop a configuration tool to allow them to design cold-rooms for their customers. Cold-rooms are typically used by supermarkets and manufacturing/processing plants to ensure that produce is held at a low enough temperature throughout its storage/processing. They needed a system that would allow them to select and configure all of the components and controls needed to build the cold-rooms. The design tool would be used by consultants, wholesalers and installers who would access Danfoss's website to order the cold-room kit on-line.
Danfoss had a clear picture of their client-side requirements, including an interactive graphical user interface to allow quick and simple selection of components.
Danfoss requested that this application be developed as ASPs. We used COM/DLLs objects for the core selection engine to handle the complex mathematical calculations involved in the physical modelling aspect of the system.
The system, known as `CoolSelector' was launched to much acclaim at the IKK show in 2002 and has already spawned a number of imitations.
Part of the inspiration for Aria
In developing CoolSelector, we maintained a clean separation between the underlying calculation model and the user interface. This separation was to allow the system to change and expand during its lifetime and to support a variety of client interfaces including a standalone, off-line version.
CoolSelector and its underlying data model provided much of the inspiration for Aria
Description of the Existing system
The original implementation of CoolSelector uses a mix of Microsoft technologies: the client application is a set of HTML pages with extensive JavaScript support to provide interaction. The front end communicates with a server by means of an XML calling-mechanism, reminiscent of the SOAP protocol.
As a means of reducing the complexity of the JavaScript and supporting the XML data-exchange and calling-convention, a Java Applet (running within IE's JVM) is used on the client-side.
On the server-side, a set of ASPs provide integration with back-end corporate functions, such as user identification, localization and order processing. The ASPs employ a number of COM objects for input validation, database access, file access and functions such as unit conversion (metres to inches etc...).
Core calculations are implemented in C++ and rely on a SQL Server database and several further COM objects for XML access.
In all, the system comprises HTML, JavaScript, XML, ASPs, VB, Java, C++ and SQL and is deployed on a Microsoft IIS server.
The core design works well and has allowed several extensions and changes to the system to be implemented. However, during development and since deployment we identified several areas with room for improvement.
Room for improvement
There are two main areas where improvements could be made to CoolSelector: firstly the coding, and secondly the deployment.
To some extent both of these problems relate to the use of COM objects and the types of interfaces they expose. From a coding perspective, the level of access to XML and databases is too low, resulting in the use of more "plumbing" code than is desirable. From a deployment perspective the use of COM objects means having to stop and start servers and well known DLL-compatibility issues.
To a lesser extent, the design trade-offs gave rise to several problems. Firstly, using an HTML front-end requires extensive JavaScript coding to provide the required degree of interactivity: JavaScript can be difficult to maintain. Secondly, processing and calculations that could have easily been carried out on most desktop computers were instead carried out on the server with an associated time delay.
Initially, the system was intended to support a variety of browsers, but over time support issues and difficulties with subtle differences in the integration of JavaScript and the underlying object model meant that CoolSelector became an IE-only system.
Given all the above, CoolSelector Mark 1 neared the limits of what can be accomplished with an HTML-based front end.
The Aria experience
The Aria version of CoolSelector started as an experiment to see how Aria performed in the development of a rich/complex client application.
Encouraged by initial successes, we began to add new data-access features to CoolSelector using the Aria data model. Aria's data binding facilities immediately meant that a whole layer of data manipulation disappeared: instead of parsing responses and updating controls, Aria allows controls to be bound to data with a simple declaration. For CoolSelector, this meant that we could update all input fields by simply declaring the data bindings. Furthermore this binding removed another layer of custom coding used to coordinate data between pages. These advantages alone provide a persuasive argument for using Aria.
Aria also greatly simplified the construction of the user interface: HTML was not designed for the creation of interfaces like CoolSelector's and to render CoolSelector's complex interface hundreds of lines of HTML in addition to hundreds of lines of JavaScript were required. By comparison, the Aria interface requires only tens of lines of code. From a maintenance point of view, the importance of this code-length reduction cannot be underestimated: less code means less maintenance!
Next, we decided to try out some core calculations in the Aria version, and the results were astounding. Again the Aria approach paid dividends as we were able to remove large amounts of plumbing code (for XML, Database access and marshalling of server requests and responses). However, the performance impact was the biggest surprise!
We had expected that using Java in place of C++ for the intensive calculation operations needed would result in a sluggish system, but in fact, we found that un-optimized selections happened almost instantaneously instead of in the 20-30 seconds we had grown accustomed to!
Comparisons
To an extent, the results achieved are implicit in using a rich client as opposed to a thin (HTML) client. After all, the rich client provides locality of computing, one of the cornerstones of computing performance.
Perhaps the biggest win comes from the simplification of the architecture and code. Aria takes care of most of the plumbing so the application-specific code need only include the explicit business logic required. Isolating this business logic makes for easy coding and maintenance.
The Aria system comprises Java, XML and some SQL, all in all a lot simpler than the client architecture. Gone are the COM objects, simplifying the server deployment dramatically.
The gains do not stop there! Implicit in the Aria architecture is the ability to operate in an occasionally-connected environment, and therefore an off-line/standalone version is a given rather than an additional requirement. Automatic update and synchronization of an off-line version is also implicit. Therefore, a Aria CoolSelector user will see little difference whether they are on- or off-line.
From a corporate standpoint, Aria CoolSelector can still run within IE's JVM. This means that it can appear just as much a part of the corporate website as any other pages. Rebranding can be achieved by editing a single configuration file and a whole gamut of extensibility and customization features are at hand. It is easy to see how Aria as an inherently open architecture could form the basis of an industry platform.
Results
Direct comparison between the Aria and HTML versions of CoolSelector may be inappropriate as some of the code has been replaced by library code and some gains are implicit in creating a rich client application instead of an HTML client. That said, the Aria version of the application represents a 75% reduction in code and approximately a 50% saving in the number of subsystems used.
Selections with Aria occur in 1-2 seconds, compared to 20-30 seconds with HTML/COM on the same machine - a staggering 3000% improvement in performance! In a multi-tier/multi-node server environment, this would translate to almost a complete removal of the work load. From an application-development point of view, the performance gain is significant in that it opens up the possibility of adding features such as simulation and diagnostic capabilities. Significantly, the Aria version of CoolSelector implicitly includes an updatable, standalone client-application as one of the many other functionality gains. Not only does this make CoolSelector accessible to a wider audience but it also makes it feasible to use CoolSelector on a broader range of devices (WebPads/Tablets/PDAs) some of which may be used by field workers such as service technicians.
Features
CoolSelector has many advanced features. First of all it simplifies the task of choosing a coldroom system for a specific market niche. In the screenshot below you can see the main configuration options on the left hand side. A refrigeration engineer would be more than familiar with these settings and indeed some of these settings such as the voltages would be regional specific.
CoolSelector will remember the user preferences so that once the sytem has been used there is probably no need to set these options very often. Selecting a system then becomes a matter of choosing the appropriate options and entering some operating conditions.
Remember CoolSelector is built using AWT and with just the components built into Aria..
Notice how the settings page contains a language button. This button pops up a dialog where you can choose the language in which the application is displayed. The localization of CoolSelector uses the very same techniques as described in this manual, so you can see that is possible to translate a complete application using the simple methods we described. Here's the same page in German.
CoolSelector featues an interactive way of setting the load. Either the users can enter the data on the top half of the page in a form or they can setup the load interactively by clicking on various parts of the graphic at the bottom. Rules and validations are applied to both.
The beauty of a rich-client application is its ability to take advantage of local computing power and CoolSelector does this to great effect. Load calculations and selections are instantaneous and this is a vast improvement over web based systems. The ease with which the system can be programmed also lends itself to adding more powerful and compelling user interaction.
CoolSelector can work on-line or off-line. In an on-line mode CoolSelector will check for connectivity and provide extra product information from Danfoss's corporate website.
In the screenshot below some information about a component is being displayed.
The Web button provides a link to the Internet usings the JDIC web browser component.
Ultimately the application is an e-commerce application and we get a list of part numbers ready for ordering.
For off-line users and for project mangement purposes CoolSelector also produces detailed summary information that can be saved for quality control purposes.
The summary information can even be exported and printed. The export features include export to office formats so that the selection can be reported as part of a larger document, for example a design specification or as an offer document to a prospective client.
And for the techies in the business there are even diagrams showing the characteristics of the proposed systems operation:
