Connecting the {Dots}

Please check this out -  JDeveloper and ADF Satisfaction Survey - Need Your Input

If you want to read the adf-config.xml entries from Java code, try getting ADFConfig object from ADFContext and read the map of entries by passing specific name spaces. An example is copied below- ADFContext aDFContext = ADFContext.getCurrent(); ADFConfig adfConfig= aDFContext.getADFConfig(); Map map= adfConfig.getConfigObject("http://xmlns.oracle.com/adfm/config"); Long rowLimit=(Long)map.get("jbo.row.limit");

Copying simple example for af:treeTable whose child column displays af:inputComboboxListOfValues component <af:treeTable value="#{bindings.DepartmentsView2.treeModel}" var="node" selectionListener="#{bindings.DepartmentsView2.treeModel.makeCurrent}" rowSelection="single" id="tt1"> <f:facet name="nodeStamp"> <af:column id="c1"> <af:outputText value="#{node}" id="ot1"/> </af:column> </f:facet> <f:facet name="pathStamp"> <af:outputText value="#{node}" id="ot2"/> </f:facet> <af:column headerText="Manager ID" id="c10"> <af:inputComboboxListOfValues rendered="#{not empty node.EmployeeId}" id="managerIdId" ...

An excellent initiative. Refer Grant's blog post - Your Chance to Change the ADF Future   for more details.

In this post I'm sharing an approach to trigger the validation once for the entire entity collection when you commit the transaction. Steps : Define a method validator for the entity object. In the Add Validation Rule dialog, select the Validation Execution tab, and choose Defer the execution to Transaction Level  Implement the validation method in your entity implementation class. An example is shown below: /** * Validation method for Departments. */ public boolean validateDepartments(ArrayList ctxList) { Iterator iter = ctxList.iterator(); while (iter.hasNext()) { JboValidatorContext entValContext = (JboValidatorContext)iter.next(); DepartmentsImpl deptEO = (DepartmentsImpl)entValContext.getSource(); if (deptEO.getDepartmentName() == null) { // if Dept is null, throw error- this is just an example to illustrate the usage of this method return false; } ...

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