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.
