Thursday 29 November 2007

ADF-BC/JSF Performing case insensitive searches

I have been asked to implement a service request system that will allow a company to record service requests from customer via a telephone line. The difference with oracle's SRDemo application is that in my case SR's will be entered by telephone operators and be assigned to departments and not to technicians

Anyway the application still offers a SRSearch page that allows telephone operators and managers to filter the service request list and here is where my problem started since they asked me if the QBE system would match parts of the requester first or last name case insensitively.My first reaction was to tell them to enter everything in capital letters, but then I though I might give it a try and ended up like this

first I added two additional fields in my query named SearchFirstName and SearchLastName defined like this

  SELECT 
       .....
       ServiceRequest.REQUESTER_FIRST_NAME, 
       UPPER( REQUESTER_FIRST_NAME) AS SEARCH_FIRST_NAME, 
       ServiceRequest.REQUESTER_LAST_NAME, 
       UPPER( REQUESTER_LAST_NAME) AS SEARCH_LAST_NAME, 
       ......

then changed I used JavaScript in the SRSearch page to make sure that whatever the user enters in the SearchFierstName and SearchLastName fields is converted to upper case before posting.

The javascript file itself is as simple as this

/* ---------------------------------------------------------------------------
 * file SRSearchSubmit.js
 * contains code that allows to submit the SRSearch form with the first name
 * and last name fields converted to upercase.
 *
 * Date 03-12-2007
 * ---------------------------------------------------------------------------
 */
 function convert()
 {
    var firstName = document.forms["myADFForm"].elements["myADFForm:searchFirstNameField"].value;
    var lastName =  document.forms["myADFForm"].elements["myADFForm:searchLastNameField"].value;

    document.forms["myADFForm"].elements["myADFForm:searchFirstNameField"].value
      = firstName.toUpperCase();
    document.forms["myADFForm"].elements["myADFForm:searchLastNameField"].value
      = lastName.toUpperCase();

    return true;
 }

No the two final points. First we need to include the javascript file at the top of the page inside a <f:verbatim> tag. Next in order to get the names of the elements right, we need to set the id attribute of both the <h:form> and the <af:inputText> elements.

The page header part of the resulting JSF page looks like this

    <afh:html>
      <f:loadBundle basename="SRKomo" var="res"/>
      <afh:head title="#{res['application.title']}">        
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <link href="../css/oracle.css" rel="stylesheet" media="screen"/>
        <f:verbatim>
          <script src="../javascript/SRSearchSumbit.js" type="text/javascript"></script>
        </f:verbatim>
      </afh:head>
      <afh:body>
        <af:messages/>
        <h:form id="myADFForm" onsubmit="convert();">
        ...

And the definitions for the each of th two search fields like this

              <af:panelLabelAndMessage label="#{bindings.AllRequestsListSearchFirstName.label}">
                <af:inputText value="#{bindings.AllRequestsListSearchFirstName.inputValue}"
                              simple="true"
                              required="#{bindings.AllRequestsListSearchFirstName.mandatory}"
                              columns="#{bindings.AllRequestsListSearchFirstName.displayWidth}"
                              styleClass="searchTextField"
                              id="searchFirstNameField">
                  <af:validator binding="#{bindings.AllRequestsListSearchFirstName.validator}"/>
                </af:inputText>
              </af:panelLabelAndMessage>

and that did it.

Notes

  • The original info about how to place javascript into a JSF document comes from the Frank Nimphius' Blogbuster article ADF Faces: Submit a form with the Enter key.
  • I have found it very easy to understand the HTML produced by the Oracle JSF engine using Firebug. Especially the "Inspect element" function will locate the HTML code of each eleent you click on and that can save you an awfull lot of decoding trouble.

Wednesday 28 November 2007

Where is the Oracle Database alert log located ?

This is something I keep forgetting so I think that I may as well add it here.

On my Linux system the alert log is located in $ORACLE_HOME/admin/$ORACLE_SID/bdump while the exact same path -- with "\" instead of "/" -- is used for Windows.

The directory where the alert.log found is determined by the background_dump_dest initialization parameter: So the ultimate way to find it is by issuing an SQL command like :

select value 
    from v$parameter 
    where name = 'background_dump_dest';

Needless to say that the alert.log's name is alert.log and that it is a simple text file that can be opened using any text editor and that you can delete it or shrink it online.

Friday 9 November 2007

ADF/JSF Getting the current row with code executed from a table bucking bean

The following code comes from the JDeveloper Forums courtesy of Frank Nimphus. If added to any event listener fired from "inside" an ADF Table, it prints the row's 1'st attribute and the rowKey.

        FacesContext fctx = FacesContext.getCurrentInstance();
        ValueBinding vb = (ValueBinding) fctx.getApplication().createValueBinding("#{row}");
        JUCtrlValueBindingRef rwbinding = (JUCtrlValueBindingRef) vb.getValue(fctx);
        System.out.println("--- Key as String --"+rwbinding.getRow().getKey().toStringFormat(true));
        System.out.println("--- First Attribute ---"+rwbinding.getRow().getAttribute(1));

Thanks again Frank

ADF/JSF Avoiding uncought exeptions after commit.

When using Oracle JDeveloper 10.1.3.x, you can find it very tempting to create "Create/Edit Record" pages by dropping an ADF Form on a blank JSF page and then adding commit and rollback buttons in the place of the ok and cancel buttons with an action property that returns your users to the browse page.

So let's assume that your faces-config file contains a navigation case labeled "return", that leads from you edit page back to your browse page. In cases like these, the code for the commit button will more or less look like this

                      <af:commandButton 
                                     actionListener="#{bindings.Commit.execute}"
                                     text="Ok" 
                                     action="return"
                                     id="commitButton"
                                     disabled="false"/>

This approach, presents a very serious hazard, which is a bug in Oracle's JSF implementation. If any exception is thrown after commit, the framework moves to the page designated by the navigation case and the error messages are not being displayed at all.

To make matters worse, you end up with on open transaction and nothing else entered in this manner ever gets stored in your database while you users have no way to realize that something has gone wrong. I had raised an SR for this that ended up in a one off patch (5630740) for JDeveloper 10.1.3.2.

I run into this problem again in am application that I developed recently using JDeveloper 10.1.3.3. And then it hit me. The solution was as simple as the Egg of Columbus. The only thing that needs to be done is to bind the commit button action in a backing bean. JDeveloper will then change the button tag into something like :

                      <af:commandButton 
                                    text="Accept"
                                    id="commitButton"
                                    disabled="false"
                                    action="#{backing_Edit.commitButton_action}"/>

... create the following code :

    public String commitButton_action()
    {
        BindingContainer bindings = getBindings();
        OperationBinding operationBinding =
            bindings.getOperationBinding("Commit");
        Object result = operationBinding.execute();
        if (!operationBinding.getErrors().isEmpty()) {
            return null;
        }
        return "return";
    }

... and that does it. Commit exception messages are displayed correctly and everyone is happy.

In case you have many edit pages with different navigation case labels then you might wish to create a solution that is a little more sophisticated and closer to the OO paradigm. In a case like this I suggest that you create a base class to be the parent of all your page backing beans and add the following method.

public class MyBackingBase
{
    protected String executeCommit( BindingContainer bindings, String successValue)
    {
        OperationBinding commitBinding =
            bindings.getOperationBinding("Commit");
        
        commitBinding.execute();
                
        return commitBinding.getErrors().isEmpty() ? successValue : null;
    }
 }

Having done that the actual backing bean code could be something as simple as

    public String commitButton_action()
    {
        return executeCommit( getBindings(), "return");
    }

... and one more thing. The Copy as HTML function is not available again. I guess I 'll have to start looking why .. :-(

Wednesday 7 November 2007

JSF Passing parameters to included jsp pages

The question was brought up in the JDeveloper forum. When I started creating my first JSF pages I wanted to be able to create a menu that I could edit and make make the changes propagate to all pages immediately. So What I wanted back then was amethod to include a jsp to all my pages but also be able to pass parameters from the including page to the one being included.

The answer came from the book Mastering JavaServer Faces by Bill Dudney, Jonathan Lehr, Bill Willis and LeRoy Mattingly.

The approach is to create a subview and then include the page using a jsp:include tag. Inside the include you must use a jsp:param tag where you define the name and value of the expected JSP parameter. To cut the long story short, I tested the solution with JDeveloper 10.1.3.3 and here is the code fragment to use.

            <f:subview id="header">
                <jsp:include page="/header.jsp" flush="true">
                    <jsp:param name="pageTitle" value="Welcome to my first JSF Application"/>
                </jsp:include>
            </f:subview>
 

The included page should be surrounded by an f:subview tag. The external parameter can be accessed by an EL expression like "#{param.paramName}" and a simple example would be something like :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ page contentType="text/html;charset=ISO-8859-7"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://xmlns.oracle.com/adf/faces" prefix="af"%>
<%@ taglib uri="http://xmlns.oracle.com/adf/faces/html" prefix="afh"%>
<f:subview id="header">
  <afh:html>
    <afh:head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-7"/>
    </afh:head>
    <afh:body>
      <af:panelHeader text="#{param.pageTitle}"/>      
    </afh:body>
  </afh:html>
</f:subview>

... and one last comment. I guess that this is the first time that the Copy as HTML command works correctly in JDeveloper on Linux. :-)

Tuesday 6 November 2007

BAPI / RFC with Delphi 2006 / 2007

Six months ago I wrote an article regarding how to install and use SAP's Active X components using Delphi 6. Here is the sequel regarding Delphi 2006 and 2007.

The basic idea is still the same you only need to install SAP Logon Control version 1.1, SAP BABPI Control Version 1.2 and finally import the SAP Remote Function Call Controll (Version 5.0) type library.

To complete the task in Delphi 2006, use the following procedure:

  1. Start Delphi 2006 and create a new package using the menu File → New → Package for Delphi Win 32.
  2. Save the package and the project using a name like SAPControls
  3. From the Delphi main menu select Component → Import Component.
  4. Locate the SAP Logon Control as show in the following image and click next
  5. In the following Screen just type SAP at the pallete page name ... and press next
  6. On the next screen select Add unit to Package radio item. ... and click Finish
  7. Repeat the previous steps and install the SAP BAPI Control and the Remote function type library. Unlike Delphi 6 you should get no compiler error messages.
  8. When you are finished, right click on the SAPControls package on the project manager window and select Install from the pop up menu.
  9. That does it. Create a new project and use the components of the new SAP pallete Category as you please.

Don't worry if you misplaced your components in an other category. You can drug them into any category you wish afterwards.