Archive for the ‘Uncategorized’ Category
This post presents source code to be used as a starting point for coding a Rich UI handler. Presented are two variations giving a “minimalist” appearance based on the philosophy of “less is more”. The screens are not exposed to an internet based audience where flashy presentations designed to capture and keep the attention of the user is not a requirement. On the contrary, the screens are deliberately austere in appearance allowing the user to focus on the task at hand which is to enter and/or maintain information as it relates to the business where distractions impacting accuracy must be minimized.
The source creates a header for a title and an area below it for a collection of menu items. The menu items are just place holders to indicate this is the area where they should reside and until logic is added they essentially do nothing. If the page design does not require menu options the developer should delete them but leave the bar in which they would normally reside.
What remains below the menu bar constitutes the main body of the web page which is further divided into two sections. The first section is intended to contain widgets allowing for input of data to be provided by the user. The user data supplied is then used to retrieve information from the database to be presented in the second section that is presented below the first. If there are no business requirements that must allow the user to enter such data (i.e. part number, customer account number, policy number, etc.) then the first section should be deleted.
As mentioned above, the second section constitutes the main area where data is presented. More often than not the data presented here is retrieved using user-supplied data provided in widgets contained in the first section described above. If the application is a browse/select type where the user is allowed to see a list of data then a data grid would be presented in this section. As another example, if the first section allows for information to be entered for a new inventory item number, a customer account number or policy number, the second section would then be filled with the appropriate widgets or components to display the related data for the purpose of inquiry or maintenance.
Because the two sections are contained in a title pane the user can collapse them by selecting the downward pointing arrow at the left of each of the pane’s titles. The user may select the arrow after supplying select criteria or a policy number to retrieve the information related to minimize its space on the browser screen.
The Source Code
Presented below is source code for a Rich UI handler that acts as a template or starting point for all web applications. Using a template such as this will serve to ensure all web pages are presented with a uniform appearance and behavior. This in turn will minimize training time and expense and ensure the user’s understanding of screen behavior can be applied to the next application in the system without having to rely upon guessing.
Source Template for a Rich UI Handler – Variation 1
Presented below is the source code for the first variation of the overall look which can be best described as having a “minimalist” appearance.
Fig.1 – Source template for a Rich UI handler
Source Template for a Rich UI Handler – Variation 2
Presented below is the source code for the second variation of the overall look. The only difference is the header section containing the title which has been filled with a blue color ( backgroundColor = “RGB(40,95,175)” ) with a white color for the title font.
Fig.2 – Source template for a Rich UI handler
Shown below is a screen shot for the above source code.
Attached to his post is a .PDF document that illustrates how to use Subversion (SVN), which is a version control tool that has been integrated with “Rational Developer for i” (RDi) so that EGL project source can be safe guarded.
The document presents three main topics the first of which covers the installation of Tortoise, a graphical application that provides tools to be used by Subversion administrators to manipulate source code repositories. The tool is not often used once a repository has been created. Although Tortoise is intended for use only by administrators, the topic showing installation and use is presented as background information and for reference purposes. For this reason the developer can skip this topic if they choose. The topics that follow are intended for developers.
After RDi has been installed on the developer’s machine, the document’s second topic shows how to install a plug-in for RDi so that it sees the source code repository. Once installed, the third topic presented provides the ability to enroll projects into the SVN repository, commit changes and manage conflicts with other developers.
Rather than create a somewhat long web-page chock full of images to upload the document can be downloaded by clicking this link.
On some browsers the download may not present the first page. If this occurs simply scroll down using the mouse’s scroll wheel and the first page should appear.
This post shows how a JVM variable can be employed on Tomcat’s startup command to declare a server instance as either a development server, a test server or a production server. An application can then retrieve this value during its startup processing phase to determine the database to which a connection must be made. To see how EGL can read this JVM variable value select this link.
Variable Indicating Development, Test and Production Servers
The value assigned to the parameter “runtimeEnvironment” indicates the role of the Tomcat server. For the developer’s server, usually running inside the IDE (RDi) the value for this parameter will be “localhost”. For the test and production Tomcat servers running on the iSeries, there are two valid values which are “TEST” and “PROD”. For example this parameter will designate the server as a production server:
All applications should obtain the value of this variable during its startup phase. For Java, this is a startup servlet. For EGL, it will be a service.
Shown below is the command that starts a Tomcat server. It has been modified to set the environment variable and its value, in this case, ‘PROD’.
All parameter name/value pairs begin with “-D”.
Why Do This?
The intent is to inform the application about the role of the server, i.e. the developer’s desktop machine in which case the value will default to “localhost” for the developer’s server, “TEST” for the test server and “PROD” for the production server. Once the value is obtained the application’s logic can then determine the proper database connection to use in addition to reading the correct set of property values established for the application. The diagram shown clarifies this.
This post revealed how a name/value pair can be established for a given Tomcat server instance so that an application may interrogate the value of the named parameter. With the value obtained the application’s logic can then determine the correct database to which a connection must be made. In this way the development staff can be confident their application can be safely run on a test server with the knowledge that it will not update production data. When it comes time to deploy to the production server, the application does not have to be modified in any way and its logic will again connect to the correct production oriented database as well as being able to obtain the correct values from the application’s property file.
Using Tomcat’s JVM parameter values to facilitate DB connections
This post will illustrate how a database connection can be established to one of two separate iSeries machines.
Before we get going, for some background you should probably read this post first. Its is about the configuration of the server’s (Tomcat) JVM property value for run-time environment ‘localhost’, ‘TEST’ and ‘PROD’.
The application’s externally defined property values
The application’s configuration data is contained in an external XML file, a common practice in web application development. For this discussion it will suffice to say the application’s configuration data has already been read during the application’s initialization phase conducted when the application is started. During this phase the data is cached into an EGL BasicRecord type i.e. ‘configDataRecord’ which can then be passed to the application’s services as a parameter. In this manner all services can gain access to the application’s configuration data.
Shown below are the entries placed in our XML configuration file that describe connection criteria for MACH1 and MACH2 used for the developer’s (localhost) server, the test (TEST) machine and the production (PROD) machine. (User id’s and passwords are obfuscated.) Library entries, of which there is only one in this example, are separated by spaces. Note the libraries established for each machine for each development environment. In this way, each connection for each machine is assigned to the correct library ensuring the proper set of data is used for each environment. This method ensures that the developer does not have to prefix or qualify SQL statements with embedded library names, which does not translate well when moving the application from a TEST server to a PROD server.
Fig.1 – The application’s XML configuration file
Making the Connection
Shown below is the EGL code that resides in an EGL service program. The variable ‘server’, passed to the function containing this code, is used to govern which set of logic is to be executed. The value determines the values for the variables ‘machineID’, ‘userid’ and ‘password’.
Once these values are obtained the value for ‘runtimeEnvironment’ is used to obtain the correct connection string or URL. For localhost, this value will come from the XML configuration data. For TEST or PROD, the connection URL is obtained from the JNDI-defined connection criteria established in Tomcat’s context.xml file. See this post for information about that.
Fig.2 – Tomcat’s context.xml
Problem? What problem?
While everything explained so far is accurate, there is one problem, if it can be called that. It’s more of a developmental artifact than anything else and can be spotted in the configuration file. Everything will still work, but there are entries which have been rendered superfluous. Can you spot the problem? Hint: see the JNDI entries for comparison. Post your thoughts on this in the comments section below this post.
So, there we have it. We’ve seen how Tomcat configuration and the application’s externally defined property values can facilitate connections to a given database for a whole list of different machines. The value of this effort should be self-evident, that is, it does not promote hard-coded connection criteria in the application’s code which, without modifications, would prohibit deployment across multiple run time environments represented by the developer’s machine, the test or QA machine and finally the production machine.