Creating a search page using the ADF Faces Rich Client Search Form context option

Okay, so like I said in my video on creating LOVs, I've gone ahead and made a follow-up video that actually demonstrates using the ADF Search Form context option that we used in the LOV demo as our form option. In this video, I take the view object that we created the LOV on and create a search page with a results section to highlight how easy it can be to do so using ADF.

I also refer to an example of creating a search page using a bind variable based view object that was pointed out to me by my friend Shay Shmeltzer. It is also an excellent sample, and when I was just reviewing it I had to chuckle because in my LOV demo writeup I referenced creating a af:selectOneChoice in the page designer rather than having it created and persisted on the actual View Object, Shays demo shows it, excellent! One thing to take note of though, is that the method he shows does not persist the LOV relationships that are formed when creating the page, they're only relevant for that particular page. So, if you dropped that same View Object (as we do in this search form demo) on another page you wouldn't get the LOV functionality that we get here.

Find my new video below:

So as you can see in the demo, the search form feature is a powerful, effective, and often overlooked feature in the ADF visual designer. The other thing you might have noticed is that when I showed how the controls on the execute button of the search form automatically registered the table as a partial target, there was another item registered there as well. That is because I had used the same data control to create a table on a separate tab on that same page. As a result, the button registered that table as a target as well.

This can be a nice benefit, or an unexpected behavior if you were to navigate around and suddenly a table on another part of the page that was previously displaying the full set of data from that data control was suddenly displaying a filtered set of data. There is nothing preventing you from taking the other tables off the partial target list for the search form, just be aware that the iterator containing the data under the covers has still been filtered by the actions of the search form.

If you want the data sets to be independent when you implement a search form off a data control that is used in other places; you can create an independent data control that is to be used just for the search form and results, or you would need to code a separate iterator for the data. The simpler option in my opinion would be to just use a redundant data control, but that's up to you.

Hope this provides some valuable information on an oft overlooked topic. I'm going to continue blogging on items that I come across while creating this sandbox application, but if anyone has any requests for topics feel free to email me at shaun.obrien@oracle.com and I'll see what I can do to whip something up...