Connecting the {Dots}

ADF has a very robust validation framework. Validations can be added at different layers (view, model and business services) based on your application's requirement. To learn more about the ADF validation framework, please go through the Fusion Developer's Guide for Oracle Application Development Framework . That said, however, in a real business scenario there are cases where the validation needs to be skipped (or by passed) conditionally while submitting the form. This post discusses this topic with some common use cases. Keep immediate=true A very common way to skip validation is by keeping the value for immediate attribute as 'true' for the UIComponents. Immediate attribute allow processing of components to move up to the Apply Request Values phase of the lifecycle. Use case scenario While canceling a specific action, system should not perform the validation. One possible way to achieve this is by keeping immediate=true associated with UI element. To know ...

I recently encountered an interesting use case where ADF Faces is used for the view layer and the data(model) is persisted in LDAP Store. Now the requirement is to identify the modified records/attributes and perform the update only on these records. There may be different ways to achieve this, say for example using container like Spring with AOP. But, is there any other smart approach without adding extra layer to my application's technology stack? Answer is 'Yes'. Let us explore one possible approach for this use case scenario. ELResolver The solution is based on customized ELResolver. We know that backing beans are bound to the view(jsf pages) using Expression Language(EL). ELResolver actually resolves thesa 'binding expressions' at runtime. So idea is to intercept in the invocation of setters for the backing beans through a customized ELResolver. And add the logic to track the modified attributes at this point. JSF specification enables to add customized javax.e...

Do you know how does LOV query get executed if there doesn't exist any entity instance to back up the source ViewObject? The scenario usually arises if you have LOV defined for an attribute, which is part of query panel. This article discusses this specific scenario with a use case. Use case Let us take the classical Employee entity as example. This 'Employee' is based on HR schema . The detailed entity is shown below. You can see that each Employee falls under specific Department and Manager. This means that while defining a new Employee record, it's required to associate an existing Employee as manager to the new record. To improve the usability, let us define a LOV against manager attribute in Employee ViewObject. Let us make this LOV much smarter by adding an additional requirement to filter down the values of ‘Manager LOV’ based on logged in user's Department Id. So 'Manager LOV' should display only those Employees who belong to the same Department as ...

Partial page rendering (PPR) allows small areas of a page to be refreshed without the need to redraw the entire page. I had a scenario where an af:outputText component needs to be refreshed programmatically. The <af:outputText> tag looks like as ashown below. <af:outputText id="op1" value="#{myBean.someValue}" /> To PPR the outputText component, tried calling the following API from backing bean method. AdfFacesContext.getCurrentInstance().addPartialTarget(outputTextComp); Unfortunately this didn't help me out. Also, noticed the following warning message in the server console at runtime. oracle.adfinternal.view.faces.renderkit.rich.PprResponseWriter$PPRTag finish WARNING: no PPR-capable ID found for elements of: RichOutputText[UIXFacesBeanImpl, id=op1] Further investigation on the above issue revealed some interesting points. Let me try summarizing them below. Why does Programmatic PPR fail for <af:outputText>? In an attempt to reduce content...