ORACLE-BASE Blog Aggregator

Following on from the Property Sets and Declarative View Object posts, another new feature in ADF Business Components in JDeveloper 11g is the “Static List View Object”.

To create a Static List View Object, via the View Object Wizard you select the “Rows populated at design time (Static List)” option:

You then define the individual attributes of the VO yourself similar to a programmatic VO:

Then manually create the actual rows and attribute values yourself, hardcoded:

It’s even possible to import the data at design time from the Import button on this same screen using a CSV file.

The key advantage of the Static List View Object is it’s suitable for small datasets that never change. A great example would be gender values (M = Male, F = Female) or statuses (O = Open, C = Closed), or in Australia where the Australian State values are set at 8 (ACT, NT, NSW, QLD, SA, TAS, VIC, WA) and unlikely to change anytime soon (ignoring the obligatory “come-the-revolution” quotes ;).

Prior to the static list, in 10.1.3 one “hack” way to create a static VO was to create a R/O VO with a SELECT statement similare to following to load in some hard coded values:

SELECT ‘a hardcoded value’ FROM DUAL
UNION ALL
SELECT ‘another hardcoded value’ FROM DUAL

This was a kludge and required a database roundtrip to return the values. Simply not ideal.

With the new 11g feature, there’s a valid argument that such data should be in fact stored in a database table anyway. Yet it’s really upto you as the well-informed-programmer to decide what would be suitable for a Static List VO as separate to a normal R/W or R/O View Object. Note Oracle recommends in their JDev 11g documentation that the Static List is only suitable for 100 rows or less, otherwise use a database derived VO anyway.

I’ve also found Static List VOs suitable for stub VOs in creating ADF Faces RC web page mockups for demonstration purposes, where the database tables have yet to be designed. We instead create some dummy data Static List VOs, some web pages based on those VOs, and it looks like the pages are showing real data. A key problem with this approach though is if you then need to transform the Static List VOs into real database VOs, it’s a pain in the butt, because you need to delete the Static List VO and all its dependencies, create the new database derived VO, and then plug this correctly back into the web page and bindings. Hint hint Oracle, a “transform” VO facility would be neat.

Note that Static List VOs are a great candidate for the new Shared Application Module feature, of which Avrom Roy-Faderman has recently posted about in part 1 and part 2.