ORACLE-BASE Blog Aggregator

Oops, forgot to post about Saturday in San Fran at OOW08.

One of the things I like to do when visiting another country is sit down and read some local newspapers to get a feel for what’s happening locally. Though American news filters through the syndicated news channels back to Australia, the pure breadth of coverage is not there.

Of course the news in the States right now is all doom-and-gloom about the economy and Wall Street. Both papers I browsed were 75%, if not 95% about the economic crisis, with a large focus on stocks, federal intervention, politics and the blame game. I was surprised by the inclusion of The Wall Street Journal story As Times Turn Tough,New York’s Wealthy Economize. “Oh boo hoo poor American rich people, you can’t afford a nose job, I feel so sorry for you.” It took me most of the day to find a story that considered the impact on the average American thanks to Time publishing Forget Wall Street. What about the rest of us?

Of course it’s also a fascinating time with the race for the American Presidency, from both inside the States and out. One thing I’ve always found odd as an Aussie travelling to other countries is how patriotic other countries are, and in turn how much the general population is willing to visibly show their preference for political parties. Across from the hotel I’m staying at somebody has placed an Obama for President poster 8 stories up on a balcony nobody can see, and yesterday I spotted this poster near China Town. I just can’t in living memory remember somebody in Australia putting something similar up, like a “I Love Kevin” poster, or a glowing picture of Little Johnny’s glowing mug.

Of course OOW is far away from the local economic and political issues.

Saturday afternoon proved a great day to catch up with fellow Oracle ACEs and bloggers, Doug Burns, Tim Hall, Lucas Jellema, Marcel Kratchovil, with much speculation about the big OOW announcements.

Given that I’ve just sat in on the Sunday ACE Director meeting where some of the announcements have been either made or hinted at, it’s a fun game to think back to our discussions yesterday to see how correct they were. Some of the announcements are completely embargoed until the keynotes so we can’t talk about them. And as I have such poor memory of what we can/can’t talk about, I’ll keep mum till each keynote .

Monday’s my Back to Basics Web Services presentation and the start of the Oracle Develop sessions I’ll attend. Should be an interesting day as long as the jet lag doesn’t kick in.

Disclaimer: I’m at OOW08 as part of the Oracle ACE Director program.

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.

Following on from my Property Sets post, another new feature in ADF Business Components for JDeveloper 11g is the “Declarative View Object”.

To create a Declarative View Object, you need a View Object based on an Entity Object, and under the Query page of the View Object Wizard or Editor, you set the SQL Mode to Declarative:

On switching a View Object to the Declarative SQL Mode option you’ll notice the Wizard/Editor hides the SQL Query from you, instead providing an interface to modify the Where clause by selecting and/or constructing View Criteria, and selecting View Object attributes to participate in the Order By clause.

The key to Declarative View Object is they calculate the SQL statement to execute at runtime from the underlying Entity Object’s database table and attribute database columns. With the previous Normal and Expert modes, the SQL query was effectively defined at design time by the programmer. The Declarative VO approach reminds me of how Oracle Forms works, in the fact that Oracle Forms uses the Block-table and Item-column mappings to construct the SQL statement at runtime; there is no complete SQL query you can look at design time in Forms.

The main advantage of Declarative mode is it removes the need to understand SQL queries, including the Where and Order By clauses. The query is now effectively hidden from the programmer.

I can hear a million Oracle programmers asking “why would we want to do that?” Taking the broad idea that not all programmers are born equal, and not all programmers know SQL, moving to a Declarative approach will assist such non-SQL-savvy programmers, as well as beginners or business users in working with ADF.

Another advantage is this approach uses the new 11g VO View Criteria feature in specifying the filtering Where clause. The View Criteria feature is a powerful one as it allows the programmer to name each Where clause essentially, and reuse that Where clause throughout the program, potentially in combination with other named View Criteria. For an example of this reuse have a look at how the new LOV controls in ADF Faces Rich Client support the defined View Criteria.

Obviously Declarative View Objects aren’t for everyone, but they provide an interesting new feature extending the declarative programming concept in JDeveloper. Soon there wont be much programming left to actually do!

One caveat I need to state with this post, and I forgot previously with the Property Sets post, is this feature is currently available in the JDev 11g Drop 6 release (and potentially TP4) that the Oracle ACE Directors have access to. There’s the possibility it wont be in the production release, but maybe we’ll know for sure in a week or so.

There’s been a few announcements recently that the upcoming version of SQL Developer will include database table modelling features. It seems to be a little know fact outside of JDeveloper circles that JDeveloper has had “offline” table modelling for sometime. The 11g release has expanded upon this feature set to include more options, that in turn make it (more of) a viable option to replace Oracle Designer physical database modelling.

(I suspect the upcoming SQL Dev modelling features just come from JDev anyhow, but I can’t confirm this).

In particular in the 11g release we now see that offline database objects have support for normal tables, external tables, index organised tables, temp tables and so on through the radio group at the top of the screen:

In addition for normal tables when selecting the Storage Options button under the Table Properties subnode, we now have the full gamut of storage clause options for the table we’re creating:

I know of a few Oracle sites that are holding onto Oracle Designer purely for its physical database modelling features only. Through the latest release of JDeveloper we can see there is the potential to drop Designer all together and go for the free JDeveloper. Now only if those sites could drop Oracle Forms too

A small post to spotlight the fact that the OOW team published a spotlight on my upcoming OOW session.