Using default search values on the JHeadstart advanced search

Lucas Jellema
0 0
Read Time:2 Minute, 58 Second

When building ADF applications using JHeadstart, one can benefit from the pretty advanced search facilities provided by JHeadstart, both through its runtime framework and as generated by the JHeadstart ADF Application Generator. One thing however it does not do is provide support for default values for search items. That means: when I go to the search section for a certain group, by default one or more search items have a value, that the user then can stray from by overriding it. In this article I will briefly discuss how we can apply such default values.....

 The JHeadstart search area is tied to an instance of the JhsSearchBean. It is this bean that holds the values of the search items as well as the list of query operators to apply to each of these values and also the methods that perform the search itself (by calling counterpart methods in the ApplicationModuleImpl). The fields in the search area have value attributes such as: value="#{searchDept.criteria.DeptLoc}", with searchDept the reference to the search bean configuration as managed bean.

We can extend from JhsSearchBean to add the support for default values for these search items:

package nl.cxs.jheadstart.controller;

import java.util.Iterator;
import java.util.Map;

import oracle.jheadstart.controller.jsf.bean.JhsSearchBean;


public class CxsJhsSearchBean extends JhsSearchBean {

    private Map defaultSearchValues;

    public CxsJhsSearchBean() {
    }

    public void applyDefaultSearchValue() {
        Iterator defaultSearchItems = getDefaultSearchValues().keySet().iterator();
        while (defaultSearchItems.hasNext())
        {
          String property = (String)defaultSearchItems.next();
          Object value = getDefaultSearchValues().get(property);
          super.getCriteria().put(property, value);
        }//while
    }

    public void setDefaultSearchValues(Map defaultSearchValues) {
        this.defaultSearchValues = defaultSearchValues;
    }

    public Map getDefaultSearchValues() {
        return defaultSearchValues;
    }
}
 

The property defaultSearchValues – a Map – holds the collection of propertyName=defaultValue pairs.

In the managed bean configuration of the search bean, we have to refer to our search bean instead of the standard JHeadstart search bean, and of course we have to provide default values for one or more of the search items – that was the whole point after all:

 

  <managed-bean>
    <managed-bean-name>searchDept</managed-bean-name>
    <managed-bean-class>nl.cxs.jheadstart.controller.CxsJhsSearchBean</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
    <managed-property>
      <property-name>bindings</property-name>
    ...
    <managed-property>
      <property-name>defaultSearchValues</property-name>
      <map-entries>
        <key-class>java.lang.String</key-class>
        <map-entry>
          <key>DeptLoc</key>
          <value>N%</value>
        </map-entry>
      </map-entries>
    </managed-property>
  </managed-bean>

We could extend the functionality easily to allow EL Expressions for values, rather than hard-coded values.

When to reset the search bean?

One important question not really addressed in JHeadstart is: when whould we clear the search bean? The search bean is a session-scope bean and after first initialization, it is never (automatically) reset. That means that when a user performs a search, navigates to a host of other pages and then returns to the page with the initial search form, the very same search criteria previously entered are still in effect. However, I can very well imagine that users would like to return to an empty – except for default values! – search form. That has yet to be provided. (for example using a InvokeMethodBean that resets the search criteria and reapplies the default search values  for the Start<GROUP> condition, configured on the JhsPageLifecycle).

About Post Author

Lucas Jellema

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Kubernetes & Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press book Oracle SOA Suite 12c Handbook. Frequent presenter on user groups and community events and conferences such as JavaOne, Oracle Code, CodeOne, NLJUG JFall and Oracle OpenWorld.
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %
Next Post

What have a Merchant, some strawberries and a performance problem in common.......

If you want to know what a Merchant, some strawberries and a performance problem have in common, you should come to the AMIS Query at thursday (28-02-2008). In this Query I will explain what these relations are, and how you could use this different way of thinking in your performance […]
%d bloggers like this: