Thursday 18 September 2008

JDev 11g ADF BC – New feature "Static List View Objects"

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.

4 comments:

Lucas Jellema said...

Hi Chris, It seems that using this static ViewObject feature is perhaps even more convenient than the Placeholder Data Control for mock ups. Can you create ViewLinks for such VOs? And are they updateable (probably not...)

best regards,

Lucas

Unknown said...

This Static List can be very useful. I know how to use that kind of VO for Validation and LOV situations. But I can't figure it out how to bind two view objects, one based on data from database and second is Static List VO to preserve i18n.

Thanks
Boris

tester said...

hi
I am using jdeveloper 11.1.2
I added criteria on my static list
but it is always returns all values
can you help me with that pls

Chris Muir said...

Ensure the Query Execute Mode you defined in the Edit View Criteria dialog is set to "In Memory" not "Database".

CM.