Connecting the {Dots}

Keep an eye on this new blog -  http://sriniraman.blogspot.com/ Srini works as  Senior Development Manager for JDeveloper IDE team and I'm sure hes planning a lot of new stuffs for you in coming days....Stay tuned !

Always it's recommended not to bind the UIComponent with managed bean with higher scopes(view, session, pageFlow, application etc.). There are multiple reasons to justify this suggestion. 1. JSF components are not Serializable, so your managed bean may fail to serialize in high availability mode. 2. Leaving stale references of the component if the bean survives the life of the view/page etc. If you really want to store a component reference in managed whose scope is higher than request, then there is utility class for your help - ComponentReference . You can take a look at org.apache.myfaces.trinidad.util.ComponentReference API to learn more. I should admit that I was not aware of this one till I learned about this from an application developer ;) ComponentReference Usage: private ComponentReference someUICompReference; public UIComponent getSomeUIComponent(){    return someUICompReference == null ?             null : someUIComp...

I've noticed quite a lot of queries in the public forum on building programmatic entity object and view objects . Let me share an example on this subject which may help you in implementing such use cases quickly. You can see a sample from Steve as well on this topic - 1 32.Programmatic View Objects Showing Master/Detail Data . Even my example also follows the same approach, of course with some minor tweaks hare and there :-) Why do you need programmatic entity and view Objects? Consider a scenario where you may need to retrieve data from a custom data source (say using third party API for example) and may need to perform some data update later on. While realizing such use cases, you my still want to leverage the declarative development support provided by the JDeveloper for building list of values, entity caching and validation, declarative transaction support etc. Though ADF got binding support for Java services, its not as rich as ADF BC implementation. One possible option is...

Putting in to action We have seen the basic theory behind the execution of  entity and view objects in the first part of this article. In the second part , let us put the theory in to action. Download You can download the sample workspace from here . [Runs with Oracle JDeveloper 11.1.2.0.0 (11g R2) + HR Schema] Please note this example does not use any API specific to 11.1.2.0 release, so you may be able to reuse the source classes in previous versions also. A glance at the implementation This example uses two model objects - Department and Employee. The 'Department' is based on DEPARTMENTS table and it follows usual entity and view object generation steps, whereas Employee is based on custom data source and the steps for generating programmatically managed Employee model object is given below. Building base classes for your programmatic entity and view objects While building a programmatic view or entity objects you may need to hook your code ...

There are use cases where you may need to refresh different parts of the page when user navigates between table or tree components which uses tree binding. In most of the cases the UI bindings(Target Data Source or TargetIterator) which needs to refreshed may share same Key attributes as your tree or tree table bindings. In such cases you can leverage the declarative support from ADF model to refresh the target iterator through 'Target Data Source' property associated with the tree binding. This topic is documented in Fusion Developers Guide, please see 29.5.4 How to Use the TargetIterator Property Note : If you have 'TargetIterator' set for tree binding, ADF binding layer will never try to execute the target iterator using the 'Key' attribute(s) of the selected row of the source iterator. Instead the binding layer may simply call setCurrentRowWithKey on the target iterator using the key from the currently selected tree node. It means that, to make this proper...

Interesting post on ADF Client Performance Optimization from Matt. Check it out - http://formattc.wordpress.com/2011/06/14/adf-client-performance-optimization-tips/

While playing around with new featured of 11.1.2.0.0 release, noticed an interesting one on data control side - declarative support for building Transactional Data Control for the business services built using JPAs. It looks cool ! There are a couple of points you may need to be aware of when you try this one. 1. Your should not keep 'Auto Commit' option 'true' for Java Service Facade if you need to defer the transaction commit. If this flag is ON, transaction will get committed as part of each service invocation from client. 2. ADF binding layer will never request the EntityManager to manage your entities at run time. So its your responsibility to associate your detached entities with PersistenceContext by calling EntityManager::persist(...) or EntityManager.merge(...) through generated wrapper method from the service facade. Generating Transactional Data Control for your Java Service Facade If you are new to EJB and never used ADF binding support to build UI...

The 11.1.2.0.0 release of ADF has added a new configuration entry in adf-config.xml file to globally set the default change event policy for the all iterators in the application. Of course, developers can override the default setting at each binding level. <adf-config xmlns="http://xmlns.oracle.com/adf/config" ... <adf-adfm-config xmlns="http://xmlns.oracle.com/adfm/config"> <defaults changeEventPolicy ="ppr" useBindVarsForViewCriteriaLiterals="true"/>

A very common demand from the community was support for adding regions at run time. The good news is that 11.1.2 release has support for adding regions dynamically which is now well supported by a task flow binding layer as well. Wow...excited? Please see 21.10 Configuring a Page To Render an Unknown Number of Regions in developers fusion developers guide to learn more about this topic. Let me give you a quick overview on the implementation. Its very easy. 1. Build the logic to return TaskFlowBindingAttributes list for dynamic task flows First step is to build a managed bean to hold your business logic for building list of oracle.adf.controller.binding.TaskFlowBindingAttributes as shown in the following code snippet. private List<TaskFlowBindingAttributes> taskFlowBindings = new ArrayList<TaskFlowBindingAttributes>(); public void buidTaskflowBindings(){ TaskFlowBindingAttributes tfBindAttr1 = new TaskFlowBindingAttributes(); tfBindAttr1.setId...

The 11.1.2 release of JDeveloper and ADF is available now. This is a very promising release and I'm sure you will really love using this smart tool. Download New Features Documentation Tutorials

If you need to invoke custom Java Script method during some specific UI(ADF Faces) component initialization, then this post is for you. Idea is to use ClientListenerSet::addBehavior(javax.el.ValueExpression) to associate a deferred value expression (referring a JavaScript method) with the UI component, which will be evaluated later when DOM is rendered on the page. Thanks to Gary Van Matre who shared this idea in an internal discussion forum public void setSomeInputField(RichInputText inpField) { this.inputField = inpField; ClientListenerSet clientListenerSet = inputField.getClientListeners(); if (clientListenerSet == null) { clientListenerSet = new ClientListenerSet(); clientListenerSet.addBehavior("new CustomCompBehavior()"); inputField.setClientListeners(clientListenerSet); } } Download You can download the sample workspace from here . [Runs with Oracle JDeveloper 11g R1 PS4(11.1.1.5.0)]

If you missed the general public call for papers, don’t worry! You have another opportunity to get included in this year’s event. You can either suggest a session or vote for one - Rich Enterprise Application Development ... Read More....

Story so far... There is a master table with immediate=true and a custom selectionListener. An editable(clickToEdit) child table needs to be refreshed programmatically from master table's custom selectionListener. <af:table id="masterTabl" immediate="true" selectionListener="#{MyBean.customSelectionHandlerForParentTable}" ... <af:table id="childTabl" partialTriggers="::masterTabl" editingMode="clickToEdit" ... public void customSelectionHandlerForParentTable(SelectionEvent selectionEvent) { RichTable childTable = getChildTable(); refreshChildTableCollectionModel() RequestContext.getCurrentInstance().addPartialTarget(childTable); } Now the fun starts...Though everything looks perfect, child table fails to reflect the refreshed CollectioModel (which is updated from the SelectionEvent of master table). Child table just repaints the previously submitted values from UI ...