Archive for October 2012
A Dialog Box that uses the InfoBus to Communicate User Driven Events
This post covers the creation of a dialog box and shows how to instantiate it, populate the titles and messages and how to communicate user driven events back to the parent program which launched it. The InfoBus is employed to communicate button events back to the parent program so that it may close the dialog and to act upon those events.
The problem which this post addresses centers on the need of the application to launch a process only after asking the user if it is OK to proceed. The application launches a dialog by injecting a specified widget into a DojoDialog. When the dialog is displayed the user can select the “Cancel” or “Approve” button. At this point the event must be communicated back to the parent application so that it can A.) close the dialog and B.) either launch the process that has been approved by the user when selecting the “Proceed” button or do nothing because the user selected the “Cancel” button. The dialog box is shown below.
The source for the dialog box and the code used by the parent application to launch it.
This section presents the source code for the dialog box along with the code used in the parent application which properly sets it up for presentation to the user.
The dialog box source.
Looking at the code there are two components that are established for a message title and an area for detail related messages. These are messageTextLabel and messagesTextArea The host program launching the dialog is responsible for populating these. In addition there are two functions which handle the button events. These are ApproveButton_onClick(event Event in) and CancelButton_onClick(event Event in)
Fig.1 – Source code for the dialog box (ApproveDialog.egl)
The code used by the parent application to present the dialog box
Shown below is the source code for the function in the parent application which launches the dialog box. It shows how it instantiates an object derived from the source presented above and how it injects the object into a DojoDialog box which simply acts as the container or frame for the object which represents its main body. It also shows how those message components are used.
Fig. 2 – The Service Return function that launches the dialog box.
The service return function above determines if the process has already been performed. While the process can be performed more than once, it is desirable to inform the user before proceeding. The dialog box is used present the outcome of that process to the user so that they can either cancel or proceed.
So far, we’ve shown how a simple widget that acts as the main body for a dialog box is injected into a DojoDialog component that acts as its container. When the DojoDialog is presented to the user they can interact by selecting one of the two available buttons. The buttons then fire the appropriate event functions which we’ll focus on in the next section.
Using the InfoBus to provide a communication link
The parent application relies upon the InfoBus to receive information about events taking place between the user and the dialog box. To receive this information the following lines are added to the start() function in the parent application.
Fig.3 – The Parent Application. Register to the InfoBus the names of the callback functions.
See Fig. 5 for details of these functions, also in the parent application.
As seen in figure 2, the parent application “owns” the dialog meaning it holds a reference to the dialog object. When displayed the dialog is holding a conversation with the user who can select one of two buttons. No matter which button is selected, the dialog “owns” that event. There are 2 problems to be solved here, the first being the dialog cannot close itself, since it is the application which holds the object reference to the dialog. Any attempt by the dialog to close itself results in an “object not found” error. The second problem is then how to communicate the button event back to the application so that it can close the dialog, since it holds the reference to it, and then either do nothing or proceed with the process.
To accomplish this, the dialog has these button-event functions ApproveButton_onClick(event Event in) and CancelButton_onClick(event Event in), shown below.
Fig.4 – The dialog’s button-event functions
They are called when either the Approve and Cancel button are selected. These functions use the InfoBus to “publish” the need to call a function that resides in the parent application. Notice that the constants used (their values are arbitrary) are the same constants used by the parent application’s start up processing which registered the call-back functions. Those functions that are in the parent application are going to get called whenever one of the functions are called.
The constants CONST_APPROVAL_PROCESS_APPROVE_DIALOG_APPROVE_EVENT and CONST_APPROVAL_PROCESS_APPROVE_DIALOG_CANCEL_EVENT of the ConstantsLibrary are used by the Infobus.publish command to establish links back to the parent application’s ApproveDialogCancelButtonInfoBusCallBack and ApproveDialogApproveButtonInfoBusCallBack functions. The values of the constants are arbitrary in nature meaning their values don’t really matter. They simply act as a handle or a means by which a lookup can be performed so that the proper function can be called when the user selects either the “Cancel” or “Approve” button.
When the user selects either button provided by the dialog the function in the parent application is called which then closes the dialog and then proceeds with the appropriate processing.
Fig. 5 – The event functions for the Approve and Cancel buttons.
Shown here is the parent application after the user has selected the “Approve” button. As a result, another dialog is presented which indicates the process has been launched.
This post showed how to create a somewhat reusable dialog box to be injected into a DojoDialog component which was then instantiated, initialized and presented by the parent application. The problem of communicating dialog button events back to the parent application was addressed by the use of the InfoBus which calls the appropriate functions for further processing by the parent program.
Using Java Mail to Send eMail with or without Attachments
This post presents a single Java class that can be used without modification in any application supporting Java or calls to methods of a Java class such as EGL or RPG.
The External Type describing the Java methods
Shown below is the EGL External Type that is used to expose the methods of the Java class used to send email. The details of the methods are revealed by the Java class source code.
Fig.1 – The EGL External Type
To send email, the EGL developer needs only to call the ‘Setter’ functions to provide the values needed by the process. Once the values have been established, to send the email, call the function ‘sendEmail()’. Present is a detailed list of the functions showing how to use them and what to expect.
- function setMailServerAddress( value string in )
This is the Address of the eMail server i.e. 123.456.789.1
This value is mandatory.
- function setMailServerPort( value string in )
Port of the eMail server i.e. 25
This value is mandatory.
- function setMailSentFromAddress( value string in )
The address of the sender i.e. DoNotReply@yourcompany.com
This value is mandatory.
- function setMailSentToAddress( value string in )
The destination address i.e. email@example.com
This value is mandatory.
- function setMailSentCcToAddress( value string in )
The list of addresses for the carbon-copy i.e. firstname.lastname@example.org, email@example.com
This value is optional. One or more addresses can be supplied but must be separated with commas.
- function setSubject( value string in )
The subject of the email
This value is mandatory.
- function setMessageText( value string in )
The Message text
This value is optional.
- function setMailAttachmentPath( value string in )
The path of the directory containing the attachment file i.e.
During development: C:/Desk/AppDevEGL/ClaimChecksApproval/ClaimChecksApprovalProject/WebContent/content/ or During Testing: tomcat\TomcatTEST\webapps\ClaimChecksApproval\content\ or For production: tomcat\TomcatPROD\webapps\ClaimChecksApproval\content\
This property is optional however, if the setMailAttachmentFileName is provided this is
- function setMailAttachmentFileName(value string in )
The file name of the attachment file i.e.
This property is optional however, if the MailAttachmentPath is provided this is
- function sendEmail() returns(string)
Once all of the required properties have been established, call this method to send the email.
The method returns a list of messages related to the process indicating success or failure and
are suitable for logging which is highly recommended.
The Java Class
Below is the Java class. The details behind the functions presented in the EGL External Type (Fig 1) above are revealed.
Fig.2 – The Java Class that does all the work.
The EGL Code that goes into the Service program.
Shown below is the segment of code that is added to the Service part. In addition to the External Type shown in Fig 1., it is all the code required by the EGL developer to create and send an email.
All of the heavy work is being accomplished by the Java class, SendMail shown in Fig. 2.
Fig.3 – The EGL code used to eMail from an EGL Service
As can be seen, sending eMail from EGL is easily accomplished by the use of a simple Java class. Packaged into a .jar file and included in any EGL project it can be reused across many projects.