Database Reference
In-Depth Information
In the menu, we are going to differentiate two sets of menu buttons that we are going to display.
These sets of buttons are located on two Java Swing JPanel components, topMenuPanel and
bottomMenuPanel . Collecting the buttons in this way allows us to disable one of the sets of buttons by
walking through all the components on a JPanel in a for loop and calling the setEnabled() method for
each component.
We split the buttons into two sets because for functions represented by the topMenuPanel we will be
acting with the privileges of the security administration interface (this application) and using Oracle
connections associated with that application. However, for the functions represented by the
bottomMenuPanel we will connect as a different, designated application and will be managing the
connection strings associated with that application.
When the Login screen closes, after a successful two-factor authentication, the OJSAdmin screen
becomes visible, because thread processing for the instantiation of Login has completed, and returns to
the OJSAdmin.ojsInit() method, Listing 12-11. At that point, the application user can select from the
menu options. If, for example, the user selects the Add/Modify User button, the event will call the
addUserButton_actionPerformed() method (Listing 12-12), which instantiates a JavaBean for that
activity, new AddUser() . Each of those activity screens that are available from the OJSAdmin menu will
both hide the OJSAdmin menu screen and make it visible once again. They can do this because we pass
the menu by reference to the constructor for the activity screen—note the reference to this in the call to
instantiate a new AddUser class in Listing 12-12.
Listing 12-12. Action Method for the Add /Modify User Button
private void addUserButton_actionPerformed(ActionEvent e) {
new AddUser( this );
}
Add/Modify User Functional Screen
Before we delve into the code and operation of our Add/Modify User functional screen, let's review the
reasons we have this screen in the first place. Recall that we added a table in the HR schema named
t_emp_mobile_nos . We are using that table to store cell phone and pager numbers, and we also store (for
convenience) the operating-system user ID of the employee. We need to maintain that data to
accomplish both single sign-on and two-factor authentication. Additionally, we use the e-mail address
in the HR.EMPLOYEES table for two-factor authentication, so we want to be able to edit that.
In order to maintain the HR data, we want a functional screen like our Add/Modify User screen,
shown in Figure 12-3. This security administration interface is not the right place to maintain employee
data, but we will permit it here in order to demonstrate our secure query and update procedures that we
developed in Chapter 7. We will enable viewing and updating the sensitive SALARY and COMMISSION_PCT
columns.
 
Search WWH ::




Custom Search