Connecting the {Dots}

In some specific use case scenarios both entity objects and stored procedures may need to co exist in your business logic implementation. This may arise if you are migrating(replacing) existing applications with ADF based application, and your customer wants to reuse some pieces from the legacy application. When you start identifying reusable pieces, in most of the cases, all eyes may be on stored procedures - we may need to accept the realities ;). As the data update logic is scattered across entity objects and stored procedure you may end up in calling DBTransaction::postChanges() to post the entity changes to data base before invoking stored procedure. Usage of DBTransaction::postChanges() is permitted if you commit the transaction within the same request. However there are some points you may need to aware of to make your implementation more perfect.  To understand the DBTransaction::postChanges(), let us take step back and analyze the transaction commit cycl...

Check out Job: IRC1600560 in irecruitment.oracle.com

If you have have a task flow designed to use shared data control, and still don't want different instances of task flows to use same view object instances, then this post is for you. Use case: Multiple instances of task flow should share same transaction context, however each UI should work independently when they are embedded in a parent page. As of now, there is no direct support for this. In this post I'm sharing a work around solution for this kind of scenario. Solution: As I said earlier, this is just a work around solution, and intended to give you some idea on the implementation. Feel free to modify the code in the attached sample to meet your use cases. Step 1 . Edit the iterator used for for those pages fragments which needs to work independently, and alter binding for the view object instance used for this iterator to use an EL. EL takes the view object instance name from a PageFlow scoped variable. <iterator Binds="#{pageFlowScope.VOInstName}...

Answer is YES for certain use cases where 1. Recalculation of transient attributes are expensive and 2. If the run time needs to touch PK attribute multiple times while serving requests from a client. An example for this scenario may be expanding multiple level of tree node. Please note that in this case the value of transient attributes are getting recalculated each time. In such scenarios, better go for other option like SQL derived attributes, if feasible. Thanks to Blaise Ribet who shared this point!

In today's post, I'm Sharing a simple application which make use of ViewObjectImpl::prepareRowSetForQuery(ViewRowSetImpl vrs) on LOV source view object to alter the query at run time. LOV switcher is the ideal solution to switch LOVs at runtime. However there are odd scenarios where you may have N number of data sources for LOV which is known only at run time. This approach may work for you in such cases. [ The concept used in this post is inspired by a solution provided by Steve Muench in an internal discussion thread ] Download You can download the sample workspace from here . [Runs with Oracle JDeveloper 11.1.2.0.0 (11g R2) + HR Schema] A glance at the implementation 1. Run test.jspx 2. Data source for LOV defined on ManagerId changes based on the values keyed in for DepartmentId field. If you leave Department empty, data is queried from EMPLOYEES table. If DepartmentId present for the row data for LOV is queried from DEPARTMENTS table for DepartmentId. The que...

Hot Deployment was one of the coolest feature of 11.1.2.0.0 release. Look like there are lot of confusion centered around on this topic. This post is meant for clarifying the offerings on Hot Deployment available with JDeveloper 11.1.2.0.0 release Hot Deployment - What Works and What's Promising? Please see 36.4 Reloading Oracle ADF Metadata in Integrated WebLogic Server in Fusion Developers Guide. Below is the excerpt for your quick reference .... JDeveloper support for hot reloading of Oracle ADF metadata is an alternative to quitting the running application, editing your project's XML definition files, redeploying, and rerunning the application in Integrated WebLogic Server to view the latest changes. Changes that you make to the Fusion web application projects will not be picked up automatically by an application that you have deployed to Integrated WebLogic Server. You can, however, reload metadata from the data model project and user interface project any time you ...