Showing posts from February, 2010

Getting hold of the http request object (ServletRequest) in ADF

Anyhow, this piece of java code can be used to access the http request object, if needed:
Normally, i'm not in favour of jumping through hoops to do things that the framework doesn't provide. If it's a framework shortcoming, by all means, go with a good lightweight workaround. But report it, get it fixed!

If the restriction is by design, then look for better ways to achieve the same outcome with the framework's capability (rather than going with pre-concieved notions of what should have been)
In ADF, there are a set of implicit objects that allow declarative, EL access to the most commonly needed data/operations.
The closest to the good old ServletRequest is the requestScope, but somehow, it doesn't seem to contain all the information that the full fledged http request has - this might be by design but I have no evidence either way (I speak as of

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 httprequest 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'…

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 Entit…