Sunday, October 5, 2008

Multiple LOV's per Attribute in JDeveloper 11g

During OOW 2008 I have attended Steve Muench talk about new features in ADF Business Components available in 11g release - Oracle ADF: New Declarative Validation, LOV, Search, and Services Features. Those features will be available in Production release, announced to appear this month. However, Oracle ACE Directors already have access to production release candidate - JDeveloper 11g Release Candidate for ACE Directors, so I'm able to test those new features.

Very imporant new feature for me - possibility to define multiple LOV's per one attribute. Previously it was possible to have only one LOV defined in Model layer per attribute. In this post I will describe how it works, based on mentioned Steve Muench presentation, and will publish sample application I have developed - LOV_Multiple.zip. You will not be able to run this sample in TP4, only in production when it will be available (I hope very soon).

My sample is based on HR schema, it contains one main View object - EmployeesView and two read-only View objects for LOV's - DepartmentsView and DepartmentsEuropeView. Those two LOV's are based on different SQL statements:


With multiple LOV's per attribute feature, we can use now two or more View objects with different SQL statements for the same attribute. For example, basic SQL statment in DepartmentsView, returns all departments:


And SQL statment in DepartmentsEuropeView, returns departments only from Europe:


Here is a sample screen, where you can see multiple LOV's per attribute defined:


I have defined in this sample, two LOV's for DepartmentId attribute - LOV_Department and LOV_Department_Europe. There is List of Values Switcher attribute defined - lovAttr. This attribute returns LOV name to be used, I have created it as Transient attribute in Employees View object. In its getter method I'm doing a check - if current region is Europe I'm using LOV only with European departments, otherwise default LOV with all departments is used:


On runtime, if employee is based in European department - DepartmentId LOV will use DepartmentsEuropeView and will list only departments from Europe:


In other case, default LOV will be used with all available departments listed:

12 comments:

Ideas Buster Coin Coin (IBCC) said...

Hi.

Nice new 11g feature. And what about bind variable in the lov ? That wasn't working in tp4.

Andrejus Baranovskis said...

Hi,

What you mean by bind variable in the LOV?

Regards,
Andrejus

Ideas Buster Coin Coin (IBCC) said...

Well, the lov is a view object, right ? So you can have a bind variable in the query and put the value at runtime or programactily.

It didn't work with tp4.

That's what I meant :)

Regards

Andrejus Baranovskis said...

I have tried to use bind variable with LOV in cascading LOV. It was working, so I assume it works :)

Andrejus

michaelloveusa said...

I cannot seem to get it to call my switcher method. I get no errors, just never gets called. When I set my default to my non-standard list, I still get the standard list. It seems like it is never using this functionality. Any ideas?

Andrejus Baranovskis said...

Have you tried to run my sample app?

Regards,
Andrej

michaelloveusa said...

I was trying to do it in my backing bean instead of the row impl!

michaelloveusa said...

FYI - The default functionality does not appear to be based on which item is selected as default, but instead, it is always the first item in the list.

Anonymous said...

it doesn't work here too, only default LOV That shown
thanks

Andrejus Baranovskis said...

It works for me...

What exactly not working for you?

Andrejus

Anonymous said...

hello Andrejus,

when I try to change DeparmentId UIHint to ChoiceList instead of input list of value and use Employee view as ADF form not a table, i noticed that DepartmentId using LOV compatible with first row switcher flag

Hope to hear from you soon
Thanks

Anonymous said...

Andrejus el ejemplo me funciona pero cuando en una lista tengo nombre la LOV y lo cambio me trae la informacion del criterio de busqueda bien, pero si la vuelvo a cambiar me cambia el criterio de busqueda pero me deja mapeado los campos de LOV anterior en la tabla del resultado