Oracle Forms

Hi,

You can use bind notation:  ":Pxx_ITEM_NAME".

Regards,

Vincent

http://vincentdeelen.blogspot.com

We are looking more for something like the keyword "this" in Javascript, $(this).method. Using bind notation would be hard coding it across all the LOVs.

Dandaman184

There isn't anyway of getting the name of the item the lov is used for.

You don't mention the apex version you are using but if you are on apex 4 you could create a item plugin.

In the apex_plugin_util.print_option documentation there is an example of how to create a select list.

In this example l_values is a pl/sql table that holds all the display and return values.

See apex_plugin for more information of what attributes are available for page item plugin.

Another advantage of creating a plugin is that could also create a validation as part of the plugin that validates if the value belongs to the right LOV.

If you need any more help please specify your apex version because the apex_plugin and apex_plugin_util package differ between the different version.

Nicolette

Why dont you create individual component LOVs for each category, each one with the respective where clause?

Like...

select d,r from YOUR_LOVES
where LOV_TYPE = 'STATE_LOV'

...
where LOV_TYPE = 'GENDER_LOV'

and so on.

And name the components just the same way. This will be vey easy to handle and to maintain.

--------

The problem with that is that if you hit the wrong LOV_ID you dont get any display. (Its a generl problem with the LOV logic - or lets say, with the general html select element logic, on with the LOV is build.) So I am just working on a LOV-Item Plugin, that deals with that situation and still displays the "wrong" value with a warning icon.

TobiP

TobiP wrote:

Why dont you create individual component LOVs for each category, each one with the respective where clause?
Like...
 select d,r from YOUR_LOVES where LOV_TYPE = 'STATE_LOV' 

 ... where LOV_TYPE = 'GENDER_LOV' 

and so on.


And name the components just the same way. This will be vey easy to handle and to maintain.

That depends on your definition of easy to maintain.

If there is a new page item is added with a new lov type

In your solution you need to add the page item and an new standard lov definition. And to be totally complete add a validation for the page item that checks if the value belongs to the page type.

With the plugin solution you only have to add the page item and choose the plugin as display type.

And any changes to the table that holds to lov definitions. For example adding a start and enddate that determine the period in which the value can be chosen.

With you solution you need to change all the standard LOV's. With the plugin you only change the rendering and validation code. And when this code is in the database then  you only need to make the change in one place in depend of how many applications use the plugin.

Now your solution is the only one available for a pre apex 4 enviroment.

You mention that are building a item plugin because you also want to show the value when it isn't part of LOV_TYPE.

If the naming of your page items is standardized so that for the same LOV_TYPE only the page number in the name of the page item differs you could do the following

where lov_type = 'GENDER_LOV'
or lov_value = v('P'||:app_page_id||'_GENDER_LOV')

Nicolette

Hi Nicolette,

refering to a pageitem in the filter of  the LOV is actually a very good idea! You could use a Page-Zero item or an app item, and maybe globally have a small popup for parametrization, that sets just this one field, and maybe a global computation, that is combined with another LOV for the categories, sort of like that, and this would make it very dynamic AND certainly better maintainable than my suggestion above.

Again, in the end it just depends on the specific needs and the abilities of the developer. And in the end a custom plugin will always do the best job.