If you use a model-based LOV and you use display type "choice", then ADF nicely displays the display value, even if the table is read-only. In the screen shot below, you see the RegionName attribute displayed instead of the RegionId. This is accomplished by the model-based LOV, I did not modify the Countries
view object to include a join with Regions. Also note the sort icon, the table is sorted by RegionId. This sorting typically results in a bug reported by your test team. Europe really shouldn't come before America when sorting ascending, right?
To fix this, we could of course change the Countries
view object query and add a join with the Regions table to include the RegionName attribute. If the table is updateable, we still need the choice list, so we need to move the model-based LOV from the RegionId attribute to the RegionName attribute and hide the RegionId attribute in the table. But that is a lot of work for such a simple requirement, in particular if we have lots of model-based choice lists in our
view object. Fortunately, there is an easier way to do this, with some generic code in your
view object base class that fixes this at once for all model-based choice lists that we have defined in our application. The trick is to override the method getSortCriteria() in the base
view object class. By default, this method returns null because the sorting is done in the database through a SQL Order By clause. However, if the getSortCriteria method does return a sort
criteria the framework will perform in memory sorting which is what we need to achieve sorting by region name. So, inside this method we need to evaluate the Order By clause, and if the order by column matches an attribute that has a model-based LOV choicelist defined with a display attribute that is different from the value attribute, we need to return a sort criterria. Here is the complete code of this method:
public SortCriteria[] getSortCriteria()
{
String orderBy = getOrderByClause();
if (orderBy!=null )
{
boolean descending = false;
if (orderBy.endsWith(" DESC"))
{
descending = true;
orderBy = orderBy.substring(0,orderBy.length()-5);
}
// extract column name, is part after the dot
int dotpos = orderBy.lastIndexOf(".");
String columnName = orderBy.substring(dotpos+1);
// loop over attributes and find matching attribute
AttributeDef orderByAttrDef = null;
for (AttributeDef attrDef : getAttributeDefs())
{
if (columnName.equals(attrDef.getColumnName()))
{
orderByAttrDef = attrDef;
break;
}
}
if (orderByAttrDef!=null && "choice".equals(orderByAttrDef.getProperty("CONTROLTYPE"))
&& orderByAttrDef.getListBindingDef()!=null)
{
String orderbyAttr = orderByAttrDef.getName();
String[] displayAttrs = orderByAttrDef.getListBindingDef().getListDisplayAttrNames();
String[] listAttrs = orderByAttrDef.getListBindingDef().getListAttrNames();
// if first list display attributes is not the same as first list attribute, than the value
// displayed is different from the value copied back to the order by attribute, in which case we need to
// use our custom comparator
if (displayAttrs!=null && listAttrs!=null && displayAttrs.length>0 && !displayAttrs[0].equals(listAttrs[0]))
{
SortCriteriaImpl sc1 = new SortCriteriaImpl(orderbyAttr, descending);
SortCriteria[] sc = new SortCriteriaImpl[]{sc1};
return sc;
}
}
}
return super.getSortCriteria();
}
If this method returns a sort
criteria, then the framework will call the sort method on the
view object. The sort method uses a Comparator object to determine the sequence in which the rows should be returned. This comparator is retrieved by calling the getRowComparator method on the
view object. So, to ensure sorting by our display value, we need to override this method to return our custom comparator:
public Comparator getRowComparator()
{
return new LovDisplayAttributeRowComparator(getSortCriteria());
}
The custom comparator class extends the default RowComparator class and overrides the method compareRows and looks up the choice display value to compare the two rows. The complete code of this class is included in the sample application.
With this code in place, clicking on the Region sort icon nicely sorts the countries by RegionName, as you can see below.
When using the Query-By-Example table filter at the top of the table, you typically want to use the same choice list to filter the rows. One way to do that is documented in ADF code corner sample 16 - How To Customize the ADF Faces Table Filter.The solution in this sample is perfectly fine to use. This sample requires you to define a separate iterator binding and associated tree binding to populate the choice list in the table filter area using the af:iterator tag. You might be able to reuse the same LOV
view object instance in this iterator binding that is used as
view accessor for the model-bassed LOV. However, I have seen quite a few customers who have a generic LOV
view object (mapped to one "refcodes" table) with the bind variable values set in the LOV
view accessor. In such a scenario, some duplicate work is needed to get a dedicated
view object instance with the correct bind variables that can be used in the iterator binding. Looking for ways to maximize reuse, wouldn't it be nice if we could just reuse our model-based LOV to populate this filter choice list? Well we can. Here are the basic steps:
1. Create an attribute list binding in the page definition that we can use to retrieve the list of SelectItems needed to populate the choice list
<list StaticList="false" Uses="LOV_RegionId"
IterBinding="CountriesView1Iterator" id="RegionId"/>
We need this "current row" list binding because the implicit list binding used by the item in the table is not accessible outside a table row, we cannot use the expression #{row.bindings.RegionId} in the table filter facet.
2. Create a Map-style managed bean with the get method retrieving the list binding as key, and returning the list of SelectItems. To return this list, we take the list of selectItems contained by the list binding and replace the index number that is normally used as key value with the actual attribute value that is set by the choice list. Here is the code of the get method:
public Object get(Object key)
{
if (key instanceof FacesCtrlListBinding)
{
// we need to cast to internal class FacesCtrlListBinding rather than JUCtrlListBinding to
// be able to call getItems method. To prevent this import, we could evaluate an EL expression
// to get the list of items
FacesCtrlListBinding lb = (FacesCtrlListBinding) key;
if (cachedFilterLists.containsKey(lb.getName()))
{
return cachedFilterLists.get(lb.getName());
}
List<SelectItem> items = (List<SelectItem>)lb.getItems();
if (items==null || items.size()==0)
{
return items;
}
List<SelectItem> newItems = new ArrayList<SelectItem>();
JUCtrlValueDef def = ((JUCtrlValueDef)lb.getDef());
String valueAttr = def.getFirstAttrName();
// the items list has an index number as value, we need to replace this with the actual
// value of the attribute that is copied back by the choice list
for (int i = 0; i < items.size(); i++)
{
SelectItem si = (SelectItem) items.get(i);
Object value = lb.getValueFromList(i);
if (value instanceof Row)
{
Row row = (Row) value;
si.setValue(row.getAttribute(valueAttr));
}
else
{
// this is the "empty" row, set value to empty string so all rows will be returned
// as user no longer wants to filter on this attribute
si.setValue("");
}
newItems.add(si);
}
cachedFilterLists.put(lb.getName(), newItems);
return newItems;
}
return null;
}
Note that we added caching to speed up performance, and to handle the situation where table filters or search
criteria are set such that no rows are retrieved in the table. When there are no rows, there is no current row and the getItems method on the list binding will return no items.
An alternative approach to create the list of SelectItems would be to retrieve the iterator binding from the list binding and loop over the rows in the iterator binding rowset. Then we wouldn't need the import of the ADF internal oracle.adfinternal.
view.faces.model.binding.FacesCtrlListBinding class, but then we need to figure out the display attributes from the list binding definition, and possible separate them with a dash if multiple display attributes are defined in the LOV. Doable but less reuse and more work.
3. Inside the filter facet for the column create an af:selectOneChoice with the value property of the f:selectItems tag referencing the get method of the managed bean:
<f:facet name="filter">
<af:selectOneChoice id="soc0" autoSubmit="true"
value="#{vs.filterCriteria.RegionId}">
<!-- attention: the RegionId list binding must be created manually in the page definition! -->
<f:selectItems id="si0"
value="#{viewScope.TableFilterChoiceList[bindings.RegionId]}"/>
</af:selectOneChoice>
</f:facet>
Note that the managed bean is defined in viewScope for the caching to take effect.
Here is a screen shot of the tabe filter in action:
You can download the sample application here.
