How to show/hide operators in adf:query advanced mode

In this post, I will provide a way to modify the operators list in the ADF query panel (af:query component) - i.e. to remove and add operators to the list. 
 (at the time of writing this post I didn't realise it was already documented here: http://docs.oracle.com/cd/E14571_01/web.1111/b31974/web_search_bc.htm#ADFFD2457)




The ADF Faces af:query component is a handy tool that neatly binds to an ADF bc View criteria defined in the model. 


In the default advanced mode, the query panel allows end users to select a suitable operator to apply to the query fields. The default list of these operators (of type JboCompOper) is populated based on the field's data type and ADF is rather intelligent with this feature - for example:
a) for an LOV based field, it displays an LOV if you select the Equals operator but changes to a text field when you choose the Starts-with operator...
b) It shows you two fields if you select the between operator. 


In my sample project based on the usual emp-dept schema, I have JobId as one of the search fields. In the advanced mode, by default, JobId is shown with the following default operators:

Sometimes you would want to hide some of these. The trick is to use the CompOper tag inside the View object's XML definition. 
The CompOper tag can be nested under either ViewAttribute or ViewCriteriaItem. 
So, to hide the Equals operator, you would use the following:

After adding some more tags under my JobId ViewAttribute, my operators list now looks like this:

Assumptions/Pre requisites:
The reader is familiar with what the Employee-Department schema is, basics of ADF like View object, view criteria etc. 


References:
The list of all possible fields is available here:
http://docs.oracle.com/cd/E15051_01/apirefs.1111/e10653/constant-values.html#oracle.jbo.common.JboCompOper

Simplified J2EE view

Entity objects = business domain objects: data + validations - we would traditionally implement these using entity EJB's, hibernate objects etc. 

View Objects = Not exactly J2EE TO's - I find this an abstraction unique to ADF encapsulating the POJO and a query.
Application Module = the API interface / 'business service'. You write your logic and expose it using any convenient interface - java client, SOAP client, EJB interface etc. 

MVC (DataBindings - ADFm, the model; Pages - jsff or jspx, the view ; TaskFlows ADFc*, the controller) then resides on top of these in your ADF UI project and consumes these business services (or ones from a non ADFbc source). 


*These names are reflected in the packaging structure of Oracle's java libraries that implement these.


Anyway, that's my brief take on things, originally posted as a response here.
https://forums.oracle.com/forums/message.jspa?messageID=10161611#10161611


Here's the official patterns catalog page.
(I need to follow up on one of their definitions if purely for pedantic reasons)

Oracle OpenWorld

Due to conflicting engagements (family / clients / potential clients) I couldn't physically be there but what's broadband Internet for?! With my 'on demand' pass I will still be able to follow the 24 hour delayed recorded keynotes and other sessions.
The welcome keynote would've started now as I write and like many others, I'm eagerly awaiting news on THE Fusion Applications.

#OOW10 on twitter

That's what my my webcenter wls_spaces server throws up (It's the 64-bit Sun JDK 1.6):


Exception in thread "[STANDBY] ExecuteThread: '13' for queue: 'weblogic.kernel.D
efault (self-tuning)'" java.lang.OutOfMemoryError: PermGen space
Exception in thread "[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.De
fault (self-tuning)'" java.lang.OutOfMemoryError: PermGen space
Exception in thread "[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.De
fault (self-tuning)'" java.lang.OutOfMemoryError: PermGen space


Never happened on any of the soa servers, which seems strange because it was a frequent occurrence on the 32 bit Sun JDK (again, resolved quick and easy by using JRockit).


I will attempt to restart this with some more heap and then just install JRockit ...

My development box

The kit:
Intel i7 860 (A decent quad core, 64 bit, 8 thread processor)
6 GB Memory
Windows 7 (64 bit)
A 64 bit JDK (with a 32 bit JDK installed as backup just for JDeveloper at design time at the moment)


Running a weblogic cluster  with 2 managed SOA servers (Oracle SOA suite 11.1.1).
A weblogic admin server.
Making do with an XE database for now, the full blown Enterprise 11gR2 database - maybe later on a need basis. 


With the above running, i've already hit 5.17G of memory usage.
Another half a gig should do for JDeveloper.


But with a node manager and a BAM server, it should soon be time to stack in a set of low latency RAM cards - 8G to keep the sanity of a 'development box'; 16G be the dream.


Before that, I could do with switching off the Aero theme and other bells and whistles.
Disk transfer rate on this box is not on my side here, so i'm really not keen on anything crucial swapping in and out. So far, I haven't heard


Bottleneck:
- Not the fastest disk I/O
- Not the lowest latency RAM either; could do with a faster 8G of RAM.


Gotchas!:
1. All weblogic servers are running with the 64 bit JDK. However, the first time I attempted to start the managed servers, it went into a FORCED shutdown as soon as I entered the username  via commandline. No stacktraces could be saved for future examination. 
However, setting up boot.properties got me past this.


2. Nodemanager still coughs up this nasty error 
but so far, this setup is on a dream run.. 




Update: 2/Aug/10
Running steady at about 4.1G Physical memory. 


Update: 3/Aug/10
All servers running steady. Used in full throttle, memory usage peaked at 5.18G. 
Left undisturbed (with JDeveloper open) it steadied at 4G. 
Woke the machine from sleep (with everything still running) and the memory usage rose from ~2.7G. 


Nothing cataclysmic attempted yet except for a separate OSB server and now i've hit 5.77G
(default Xmx values so far)

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:

((ServletRequest)ADFContext.getCurrent().getEnvironment().getRequest())

 
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 11.1.1.1.0).

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.