Showing a Subset of Display Attributes in the Drop-down List with Combo box List of Values

Combo box List of Values (inputComboboxListOfValues) is supposed to be a very popular ADF Faces component for working with LOVs. Frankly speaking, this is my favorite approach when it comes to Lists of Values. In this short post I am going to focus on one feature which is often overlooked by ADF developers. If a LOV is defined by default, for example like this:

Then the framework will render the entire list of display attributes in the drop-down combo box and  in the search dialog. For the search form this is desired in our use-case. Basically, that's why all available attributes are selected. But, definitely, it would be better to show a bit shorter attribute list in the combo box. It is possible to define a subset of attributes to be shown in the drop-down list by using the Show in Combo Box option. We can specify the number of first attributes from the list to be rendered in the combo box:

Having done that, the LOV's behavior becomes more user-friendly.
Combo Box:

Search Dialog:

That's it!

User sessions, Data controls and AM pooling

Recently I was asked an interesting question about application module pooling. As we know AM pool contains application module instances referenced by user sessions, which allows a session to fetch exactly the same AM instance from the pool at the subsequent request.

And if there is more than one root application module in the application, then each of them is going to have its own AM pool:

And how about the situation when the application handles more than one instance of the same root application module. For example any kind of UI Shell application where each tab runs a task flow with isolated data control scope.

In this case a user session references several AM instances in the pool. For this particular example there are going to be four AMs in the pool referenced by one session. One for the menu and three for the tabs.

So the question is how come the framework doesn't mess it all up and knows exactly which AM instance in the pool should be used by each tab. The answer is that an application module instance in the pool is not directly referenced by a user session. Instead of that it is referenced by a SessionCookie object which is unique for each DataControl instance. Since the task flows in the application have been run with isolated data control scope, there is a separate DataControl instance for each of them.

That's it!