Thursday, October 28, 2010

Translating Display Values in ADF Rich Client LOVs


So I was working on a sample app I've been developing and came across an issue with getting a LOV to operate like I had expected it to. So, here is the db diagram of the tables involved. I have the standard ADF BC objects associated with this where I have the type table describing the various named types associated with the numerical id that is held in the TYPE_ID on the main component. So, on the MoveView I went ahead and created an LOV which defines the expected mapping of the ids of the TYPE_ID to the names described on the TYPE table.



So here you see the configuration of the LOV on the MoveView. Now, since the default UI hint is set as a choice list, if I just drop the view on a page it renders this by default as a selectOneChoice tag which is fine. However, if I go ahead and drop the attribute type_id directly from the data control palette I'm prompted with two options from the LOV context menu of ADF LOV Input or ADF LOV Choice List. The problem was introduced when I selected the ADF LOV Choice List. This creates as the rendering tag an "Input Combobox List of Values" which is bound to the LOV model as expected.






So here you can see the different renderings of those controls, both based on the LOV model. The problem I ran into with the control created by dragging the attribute directly from the data control palette is obvious. It lists the type names as desired instead of the type_id which is the actual table data, but once selected, the value that shows up in the collapsed control is the numerical backing value which isn't what I wanted. Thanks to Shays help we were able to come up with a simple (if perhaps not the ideal) workaround. We edited the MoveView, adding the Type table as a contributing entity and then added the name and id fields from the Type table as attributes of the MoveView. We then created a LOV definition on the newly included Name attribute.




So nothing really astonishing in creating this LOV. We then went and dropped the name attribute from the datacontrol palette to the page and dropped it as the aforementioned: "List of Values -> ADF LOV Choice List" which creates the InputComboboxListOfValues we saw before. We then went back into view object editor for the MoveView and made the TypeId attribute dependent on the Name attribute we just brought in from the Type entity. By doing this, when the Name attribute gets updated, the associated Type value will be applied. To tie this all together in the UI, we added the Name LOV control as a PartialTrigger on the TypeId control so that when we updated the Name, the TypeId control would also refresh with the appropriate data. This was mostly done for testing purposes as the Name control that we were creating was there to replace the need for the TypeId based control but we wanted to see that the associated TypeId value was indeed being set when the Name control was used. In the tests it worked perfectly! Thanks to Shay for his assistance getting this worked out.

1 comment:

  1. Thank you! My issue wasn't exactly this one, but your post helped me find the solution to it. I had used a ComboBoxListOfValues and fought trying to figure out how to display the selectItem label for days, Changing the default control to a simple comboBox took care of it.

    Seems a bit counter intuitive that we'd use a simple combo box when using a model driven LOV, but there it is.

    ReplyDelete