Something about requestScope.

I should first mention, Frank Nimpihus has an excellent viewlet on "How - to bookmark view activities in a taskflow".

Edit: I started off to address the bit about having a bookmarkable page with parameters using just the requestScope.
I started this intending to get hold of an http request parameter via adf requestScope. Turned out, the whole request URL is actually nested deep inside a requestScope object. See this: 

I then wrote this piece of code in a Filter -

ADFContext.getCurrent().getRequestScope().put("adfItemId", servletRequest.getParameter("ItemId"));

Expecting to see the value via #{requestScope.adfItemId}  on my page. That was not to be. Only digging deeper through the debugger unearthed what you see in the above screeshot.

I finally got over this and arrived at the below steps to achieve a bookmarkable page with parameters (almost identical to the viewlet linked above, except for the use of requestScope):

Step 1. Create a requestScoped 'bean' in the unbounded taskflow containing the bookmarkable page.

Step 2. Set the ItemId request parameter (set in the URL) in the requestScope parameter

Step 3. Access the value:

Read only View Object should *also* be based on Entities

This might involve a wee bit of paradigm shift for developers moving on from 10g. 
The prevailing wisdom in 10g has been to not base read-only view objects on Entities and for good reason: performance gain. 


The recommended approach in the Fusion developer guide, however, is to base all view objects on Entities - a fact that might have gone unnoticed, especially in projects newly migrating over from 10g. 


While no measurable metrics seem to be available for 10g, the Fusion developer guide (Section 39.2.2) mentions that 
"there is no significant performance degradation incurred by using the entity object to create the local cache"


Not just that, for entity based view objects, "The data in the view object will reflect the state of the local cache rather than need to return to the database for each read operation"
This is something that ANY object-relational mapping/persistence technology should have built in - so does ADFbc, with its entity and view caches. 


While any Entity usage can be marked as 'non updatable' in the VO (as discussed in the dev guide section referenced above), in 11g, there is an additional EO level property that allows you to mark the whole Entity as non-updatable. 

Possible usecases might be:
- A way of enforcing read-only access to certain data, say, in a shared service or ADFbc library.


To sum up some of the benefits of having your read-only view objects to be entity based:
1. Declarative SQL generation.
2. Reuse of common properties (like attribute hints, labels etc.) across different views of data, enforcing consistency (unless some views explicitly have to display something differently, they get to just reuse the EO properties) 
3. Additional overhead of maintaining the view-entity coordination is minimal, and possibly overshadowed by performance gains from local caching. (an expert-mode VO would need to return to DB for each read operation)

ADF Example: LOV search region fields and operators

The (11.1.1.1.0) example can be downloaded here.
Based on a recent forum thread, seems this idea could use some more 'how-to' type clarity. 

For LOV's on an ADF Faces UI, a popup dialog with search form and search results is presented to the user to facilitate search for specific values.

By default, the search form contains all queriable fields.

This example illustrates how to replace this by specific fields and/or operators chosen at design time.

1. DepartmentView has a view criteria defined as shown:

2. EmployeeView has a view accessor to DepartmentView which uses the criteria defined above (edit view accessor and shuttle the criteria from available to 'selected'

3. DepartmentName attribute of EmployeeView has an LOV defined - which is in turn based on a view accessor to DepartmentView. With the below settings, fields (and operators) defined in the criteria from DepartmentView will appear on the search region of the LOV:

PS: LOV = List of Values
LOV's are commonly defined on ViewObject attributes in 11g. That makes a more model-driven UI and keeps the business logic (that a field can hold a specific set of values) in ADFbc components. Not much work is required on the UI itself - apart from drag and drop.

ADF Sample: Declarative line item search

A common functional requirement is to search for master objects based on some attributes of its detail objects.
- Search for requisitions containing an item costing more than a given amount.
- Invoices containing invoice lines with specific item names.

ADF has purely declarative support for implementing this kind of a usecase. To illustrate, I have implemented:
A search for departments which have at least one employee whose salary is greater than the salary entered in search form.

The core concept is that a 'view link accessor' (or an association accessor in the entity layer) can (should) be seen as just another attribute.

Download the example: LineItemSearch.zip.

ADF in bite-sized pieces

I had to start this sometime 'soon'. Over a period of time you kind of just catch on and wisen up to the fact that there are going to be similar questions asked over and over and over again.
So, here goes: http://bitesizedadf.googlecode.com/
Now that it's all out there, I better keep up. Hope to keep posting something interesting at least every week (Bill, if you are reading this, it's strictly on my own time/weekends)

ORCL

Leaving Oracle in August felt like graduation more than anything else. Since then, for the first time in my career, I started working with a company whose core product or service is not software (and has a significant non profit operation). Of course, it's software, and people who design and develop it, that helps them do business better, smoother and quicker!

I literally worked in a campus for more than two years and in hindsight, it feels like I was in grad school with a stipend.

There was learning that one can only achieve in mega-corporation that now literally owns a big chunk of the industry in diverse product lines.

I got to interact with some of the best minds in the industry. There are teams and individuals that resemble startups, all part of the giant global ecosystem!

And Fusion is something that truly excited me and many others. The sheer scale of it is staggering. A brand new product suite from the ground up on shiny new technology.

Fusion was what made the past few years the best time to work at Oracle for me and i'm sure, for many others.

I now continue to be involved with the general community and some specialised groups of interest. Not vastly different being on the other side of the fence actually.

Except that what I now do at work has a quicker and more direct impact on the way my company's customers benefit from its online systems.

Detail attributes in master ViewCriteria

Step 1
Expose the accessor to child VO in Master VO

Step 2

Step 3
Add any child attributes needed in the ViewCriteria

Autumn