JHeadstart Blog

Oracle JHeadstart 10.1.3.3 is now available for download. All customers that hold a supplement option license can download it from the Consulting Supplement Option portal. For a full list of the new features, see further down in this post.

The main theme of this release is the introduction of the JHeadstart Forms2ADF Generator (JFG). It allows you to reuse Oracle Forms elements and properties when creating Oracle ADF applications. The JFG creates the Business Services (ADF Business Components) and the JHeadstart meta data (Application Definition). After that you can run the JHeadstart Application Generator to generate an ADF web application based on the User Interface definitions that have been extracted from the Oracle Form.

Currently there is no evaluation version available for JHeadstart 10.1.3.3. If you want to evaluate JHeadstart, you can download the evaluation version of JHeadstart 10.1.3.2 from the JHeadstart Product Center. If you want to evaluate the JHeadstart Forms2ADF Generator, please contact the JHeadstart Team at idevcoe_nl "at" oracle "dot" com (this funny notation is to avoid automated spam...).

Now that we have finished making this release, we have more resources available to work on JHeadstart 11g. If you plan on upgrading to JDeveloper 11g and JHeadstart 11g later, it's good to know that all your ADF Business Components and your JHeadstart application definitions (the JHeadstart meta data) will be automatically upgraded, and then you can generate ADF Faces Rich Client pages using the JHeadstart 11g Application Generator. The only thing you will have to do manually is check if your custom generator templates need changes (this can happen if there are changes in the default generator templates on which they were based). See also the JHeadstart Feature List - section Upgrading to JDeveloper R11 and Beyond.

A full list of the new features in 10.1.3.3:

• JHeadstart Forms2ADF Generator (Preview): This utility allows you to reuse Oracle Forms .fmb files to create ADF web applications. The utility creates ADF Business Components based on the blocks, LOV's and Record Groups defined in the form. It also creates a JHeadstart Application Definition file that allows you to generate fully functional web pages based on the form definition. The PL/SQL logic is extracted and displayed as documentation nodes into the Application Definition. The Application Definition Editor includes an option to move the PL/SQL logic to the database.
  This utility is in preview status, which means it is still lacking some functionality (see the JHeadstart 10.1.3.3 release notes), and has not yet proven itself in a real customer project. We invite you to test the JFG and report your findings to us. See the chapter "JHeadstart Forms2ADF Generator' in the JHeadstart Developer's Guide, section "Troubleshooting" for more information on how to send us your feedback. This utility replaces the JHeadstart Designer-Forms Migrator which is no longer available in this release.
• Integration with OraFormsFaces: OraFormsFaces is a third party JSF component library that allows you to embed Oracle Forms within your JSF application. JHeadstart eases integration with this technology through a new item display type "oraFormsfaces". By setting this item display type, and the value property of this item to the name of your Oracle Form, JHeadstart generates the OraFormsFaces JSF component into your page. For more information, see the OraFormsFaces website.
• Support for Control Groups: A new boolean group property "Bound to Model Data Collection?" allows you to create control groups which are not based on a data collection.
• Support for Unrelated Detail Groups: A new boolean group property "Dependent Data Collection?" allows you to create a databound detail group which can be based on any data collection (View Object usage) in the data control (application module), not just the data collections that have a view link to the data collection of the parent group.
• Generation of Command Buttons: A new item display type "commandButton" has been added. You can use the new action and actionListener properties to wire the generated button to an ADFm action binding or a (custom) managed bean.
• Easy Access to Value Bindings in Other Page Definitions: If you want to use a value from a value binding located in another page definition (binding container) than the current one, you can use the notation #{data.OtherPageDef.valueBinding.inputValue}. However, for this to work, this other page definition needs to be "prepared" (the refreshControl method must have been called on the page definition at the beginning of the request). To make sure you reference prepared binding containers, JHeadstart now includes a managed bean stored under the name "jhsPageDefs" which returns prepared binding containers. You can use this as follows in your EL expressions: #{jhsPageDefs['OtherPageDef'].valueBinding.inputValue}
• JHeadstart Utility: View Objects with Default Fetch SizeThis utility produces a list of view objects with fetch size set to the default of 1. To increase performance, the default fetch size should be set based on the usage of the view object in the pages. For example, a view object used to populate a drop-down list should fetch all rows at once. This utility can help you identify view objects with a misconfigured fetch size. This utility is available through the right-mouse-click menu on your ADF BC project.
• JHeadstart Utility: View Objects without Key AttributesThis utility produces a list of view objects without an attribute that is marked as key attribute. For proper functioning in an ADF Faces web application, each View Object should have at least one key attribute.The utility is available through the right-mouse-click menu on your ADF BC project.
• JHeadstart Utility: Mass Update of "Passivate State for Transient Attributes" property in View Objects.By default, ADF BC will not passivate the values of transient attributes in your View Objects. This can lead to unexpected problems when your application is in production and there are many concurrent users. This utility automatically sets "Passivate State for Transient Attributes" to true for all View Objects in the project, similar to checking this checkbox on the VO Tuning Panel tab. This utility is available through the right-mouse-click menu on your ADF BC project.
• JHeadstart Utility: Copy View Object Usages from Application Module.This utility allows you to quickly re-organize your application modules. For example, if you have one big application module that you want to split out into multiple smaller application modules, you can run this utility to copy the usages from the original application module, and then remove the VO usages you are going to put in another application module. You can also use this utility the other way around: you can merge multiple smaller application modules into one big application module. This utility is available through the right-mouse-click menu on your application mopdule. It will list the other application modules in your project where you want to copy the VO usages from.

• New features of JHeadstart 10.1.3.2
• New features of JHeadstart 10.1.3.1
• New features of JHeadstart 10.1.3.0

In JHeadstart Quick Search and Advanced Search, for each search item you can define a Query Operator. This operator determines how to query the data. Examples are contains, endsWith and greaterThan. See the JHeadstart Developer's Guide, section 7.2.4 for instructions how to change the Query Operator for an item. You can even let the application user choose the query operator.

By default, the ‘StartsWith’ operator is used for String items. In all other cases the equality operator is used.

But what if you want all your String items to use a different query operator? You don't want to explicitly set the query operator for every item.

The solution is: modify the JHeadstart Generator Template that creates the Search Beans, and add a managed property to the managed bean to set the defaultStringOperator to another value.

The next question becomes: what value to use? The 'StartsWith' operator applies the 'like' operator, and adds a wildcard % at the end of the search term. What if you want to keep on using the 'like' operator, but without the added wildcard?

You could check the allowable values of the Query Operator property in the JHeadstart Application Definition (at Item level). Unfortunately it does not list a "like" operator. You could choose the "is" operator, but then any wildcards typed in by the end user would be taken literally. You want the use of wildcards, but only if typed in!

Section 7.2.6.2 of the JHeadstart Developer's Guide explains that JHeadstart's QueryCondition class is responsible for translating the query operator names to the appropriate SQL operators and wildcard usage. Taking a look at the source code of oracle.jheadstart.model.QueryCondition (in JDeveloper, select a JHeadstart project, click Control+Minus and type in QueryCondition), sheds some light on the issue. If the query operator is "startsWith", the SQL operator is set to "like" and the wildcardUsage is set to "suffix". If the operator does not match any of the predefined values, no transformation is applied, and the passed in value is set directly as SQL operator. So, to achieve that the SQL operator is set to "like" and no wildcard is added automatically, we must set the query operator to "like".

To summarize, here are the steps to apply:

1. Copy the JHeadstart template default/misc/facesConfig/searchBean.vm to your location for custom templates, for example custom/searchBeanDefaultStringOperator.vm. For more information about using custom templates, see the JHeadstart Developer's Guide, section 4.7.2.
2. Add the following lines just before the last line that contains the end of the bean( </managed-bean> ):
   

   <managed-property>
   <property-name>defaultStringOperator</property-name>
   <value>like</value>
   </managed-property>
   

3. Modify your config/customTemplateBindings.jtp file (you may have used a different name) and add a line:
   

   SEARCH_BEAN=custom/searchBeanDefaultStringOperator.vm

   If you don't have such a file yet, you can create one in the config folder. It can be empty besides the above line.
4. If you didn't have a customTemplateBindings.jtp yet, you will also have to specify in your Application Definition file(s) that you want to use this configuration file. You do that at Service level, in the Templates tab, the first property. Set Template Binding File (.jtp) to customTemplateBindings.jtp.
5. Run the JHeadstart Application Generator for the Application Definition(s).