JHeadstart Blog

I visited Oracle Open World last week. It was a great event with a lot of news, good sessions and great parties! JHeadstart was present through 2 presentations from partners and they were both very positive about the new JHeadstart release. Always good to hear from others what they think of Oracle JHeadstart.

The first presentation was of my former colleague and Oracle Ace Lucas Jellema of Oracle Partner Amis. You may know him from his excellent and very productive blog on Oracle technology. His presentation was on JSF and ADF Faces. He showed the differences between standard JSF (reference implementation) and the richness of ADF Faces and finished with a demonstration on how JHeadstart generates ADF Faces applications. Lucas was very positive on JHeadstart: "JHeadstart 10.1.3 offers quick prototyping, consistent look & feel, easy intro for non-Java developers, high productivity". You can download his presentation from the Oracle OpenWorld content catalog site. (session id= S281846)

The second presentation was from Peter Koletzke (Quovera): Oracle JDeveloper 10g with ADF Faces and JHeadstart: Is it Oracle Forms Yet?
As the title indicates the presentation was directed to the Oracle Forms Developers community. The room was packed with about 200 attendees of whom most were Forms developers and only a few had started with Java and Oracle JDeveloper. Peter gave away the answer to his own question at the beginning. First on whether JDeveloper is comparable to Forms: "Nooooooo! but is a close second". Later on JHeadstart, "JDeveloper with JHeadstart way ahead of Forms!"  You can download his presentation from the Quovera website or the Oracle Open World content catalog site. (session id= S281920)

Peter, together with Duncan Mills, has written a book: Oracle JDeveloper 10g for Forms & PL/SQL Developers: A Guide to Web Development with Oracle ADF which is a good start to get more acquainted with ADF, chapter 16 is on JHeadstart.

In addition to these presentations Oracle Ace Steve Muench has written a nice article on Oracle JHeadstart that is published in Oracle Magazine. The title of the article is Jump-Start J2EE Development and is published in the November-December 2006 edition of Oracle Magazine. You can also read his article online.

 

I'm glad to see so much attention on the new release of Oracle JHeadstart. All the feedback from customers and partners has been very positive over the last couple of months. If you have a great story on what you or your organization did with Oracle JHeadstart please share it with us.

On the JHeadstart Discussion Forum, David Pistolero explains how to create a deep link for creation of a new row in a form-style JHeadstart Group.

See how you can use JHeadstart's Velocity Generator Templates to generate JSF / ADF Faces pages with a hyperlink that goes to another page of your application. When the hyperlink is clicked, the target page (which has a form layout style) invokes an ADF CreateInsert operation, and switches the page into JHeadstart create mode.

The JHeadstart create mode allows the same page to be used for both inserts and updates. See the JHeadstart Developer's Guide, section "Create/Update Page Mode".


Thank you for your contribution, David!

Xavier found out how to deploy his JHeadstart 10.1.2 application to Oracle Application Server 10.1.3, so I'd like to share it with you.

He followed the instructions in Ric Smith's Deploying a 10.1.2 UIX Application to a 10.1.3.x OC4J Instance. When running the application, he got an error:

java.lang.NullPointerException
at oracle.jheadstart.controller.AuthenticationFilter.doFilter (AuthenticationFilter.java:182)

The problem was caused by the AuthenticationFilter being called for requests where the ADFBindingFilter was not called. The ADFBindingFilter takes care of creating a new HttpSession, and if this is not done you get the NullPointerException.

This can be solved by changing the WEB-INF/web.xml file. The filter mappings for the AuthenticationFilter (and the CharacterEncodingFilter) should be similar to those of the ADFBindingFilter:

  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <url-pattern>*.jspx</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>action</servlet-name>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>uix</servlet-name>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>ordDeliverMedia</servlet-name>
  </filter-mapping>

So remove the existing filter mappings for AuthenticationFilter and CharacterEncodingFilter, and copy the above filter mappings instead while replacing ADFBindingFilter by AuthenticationFilter and CharacterEncodingFilter respectively.

That should do the trick. Thank you, Xavier!

OC4J 10.1.3 allows you to include Data Source definitions with your EAR file. JDeveloper 10.1.3 automatically creates such EAR Files if you deploy to Oracle Application Server 10.1.3. But what if you don't want to include the database connect information in your EAR file?

In my opinion, data sources are useful for externalizing the database connections (development, test, production, ...) from the web application. I think it's best to use the same EAR file for all environments, and have different data source definitions in each environment. The data sources should have the same name of course, but connect to different databases.

In JDeveloper 10.1.3 I had defined an Application Server connection to our Development OC4J 10.1.3 instance, and discovered that the EAR files I created with JDeveloper deployment profiles always included data source definitions. That meant that I had to change the data sources in the Test and Production application servers after deploying this EAR file.

Fortunately, I also found a way to omit the data sources from the EAR file: remove all Application Server Connections from your JDeveloper 10.1.3 installation before creating the EAR file using a deployment profile. JDeveloper then cannot determine the type of application server you deploy to, and will not include the data source definitions.

Then it became much easier to use the same EAR file for all environments!

In JHeadstart jspx pages, you can reference entries in the JHeadstart resource bundle (usually called ApplicationResources.properties), using the EL expression #{nls['KEY']}, where KEY is the key of the desired resource bundle entry.

Manually adding your own message

If you want to add your own message, you can of course write an entry in the resource bundle:

CONFIRM_DELETE=Are you sure you want to delete this row?

Then you can use this message in your JSF page by specifying:

#{nls['CONFIRM_DELETE']}

Generating the message into the page

The next level is to include this EL expression in a custom Generator Template. For example when adding a warning message to a delete button, which is also described in Lucas Jellema's post Generate 'Delete with Confirmation' in JHeadstart applications.

In the Velocity Generator Template for your custom Delete Button you could use something like:

onclick="return confirm('#{nls['CONFIRM_DELETE']}');"

That way you can generate the page, but you would still have to add the message manually to the ApplicationResources.properties file.

Generating the message into the Resource Bundle

One step further is to use the JHeadstart routine JHS.nls in your Velocity template. This method in the JhsVelocityContext class (see the JDeveloper Help menu, JHeadstart Documentation Index, Javadoc of the JHeadstart Application Generator) has many overloaded variations. The simplest takes two String arguments:

nls(java.lang.String s, java.lang.String key)

It creates a resource bundle entry KEY=s, and returns #{nls['KEY']}. In the delete warning example you would put in the generator template:

onclick="return confirm('${JHS.nls("Are you sure you want to delete this row?", "CONFIRM_DELETE")}');"

And it would create a resource bundle entry

CONFIRM_DELETE=Are you sure you want to delete this row?

You can make it more specific for each group while keeping it generic, by changing it to (suggested by Aino Andriessen):

onclick="return confirm('${JHS.nls("Are you sure you want to delete this ${JHS.current.group.displayTitleSingular}?", "${JHS.current.group.name}_CONFIRM_DELETE")}');"

This will result in (example for the Customers group):

onclick="return confirm('#{nls['CUSTOMERS_CONFIRM_DELETE']}');"
                   
and a resource bundle entry

CUSTOMERS_CONFIRM_DELETE=Are you sure you want to delete this Customer?

When the user clicks the Delete button, (s)he will see this: