Going Mobile with ADF: Programmatically Invoking SOAP Web Services with Complex Types

Introduction This 5th article in the “Going Mobile with ADF” series explains how you programmatically invoke a SOAP web service from an ADF Mobile application. It illustrates how to handle in Java the complex type that might be returned by the web service, as well as how to set up the complex types that might […]

A Hidden Gem of ADF Faces 12c: The <af:target> Tag

Introduction In JDeveloper 12c, the <af:target> tag has been added, a very powerful new ADF Faces tag which can make your life much easier and more productive when building ADF Faces pages. This post discusses how you use this new tag, and explains how specific functional requirements that used to be mind-boggling to implement, are now […]

Going Mobile with ADF – Implementing Data Caching and Syncing for Working Offline Part I

Introduction With over 90% of internet traffic now coming from mobile devices, there is a huge pressure on companies to make their customer-facing applications suitable for rendering on smart phones and tablets. A-team is involved with a number of customers who are looking for ways to adapt their existing Oracle ADF applications and make them […]

Going Mobile with ADF – Running ADF Faces on Mobile Phones and Tablets

Introduction With over 90% of internet traffic now coming from mobile devices, there is a huge pressure on companies to make their customer-facing applications suitable for rendering on smart phones and tablets. A-team is involved with a number of customers who are looking for ways to adapt their existing Oracle ADF applications and make them […]

Going Mobile with ADF – Understanding the Options

Introduction With over 90% of internet traffic now coming from mobile devices, there is a huge pressure on companies to make their customer-facing applications suitable for rendering on smart phones and tablets. A-team is involved with a number of customers who are looking for ways to adapt their existing Oracle ADF applications and make them […]

ADF Mobile – Browsing Using Swipe Actions

Introduction Using swipe actions to browse through a set of data or images is a common user interface pattern on mobile devices. This article explains a simple technique to add support for these swipe actions to your ADF Mobile pages in a declarative way. As part of this technique you will also learn how to […]

ADF Mobile – Preserving the Current Row Across Pages

Introduction  Unlike “bigADF”, the current row in ADF Mobile is not preserved across pages that bind to the same data collection in your data control. The standard approach to preserve row currency is labor intensive and not straightforward. In this article we will explain a more advanced technique to preserve the row currency which is […]

Error Handling in ADF Mobile

Introduction When writing ADF Mobile applications, you need to handle application errors and exceptions. These errors might be unexpected, for example a failing connection to a remote server, or expected errors like violation of some application business rule. The errors or exceptions might occur in the primary request thread, or in a secondary thread running […]

Rules and Best Practices for JSF Component Binding in ADF

There is a lot of confusion about how to use JSF component binding in managed beans. For many years, I thought I knew how to do it correctly, but recently I  learned some important new things from an internal e-mail discussion with Blake Sullivan, Duncan Mills, Andy Schwartz, Jobinesh Purushothaman and Matt Cooper that I want to share in this post.

A very common mistake is to bind a JSF UI Component to a managed bean which is in a scope greater than requestScope or backingBeanScope. You should not do this for two reasons:

 

  • UI Components are not serializable, so your application might fail to work correctly in a clustered environment
  • The UI component tree might not be released correctly, significantly increasing the memory load of your application. 

While marking the UIComponent property as transient in the managed bean fixes the first issue, it does not solve the second issue, and is therefore not a good option to use. The only way to address both issues is to use the org.apache.myfaces.trinidad.util.ComponentReference class. The standard UIComponent binding code like this

  RichInputText nameField;
  public void setNameField(RichInputText nameField)
  {
    this.nameField = nameField;
  }
  public RichInputText getNameField()
  {
    return nameField;
  }

should be replaced with code like this: 

  private ComponentReference nameField;
  public RichInputText getNameField()
  {
    if (nameField!=null)
    {
      return (RichInputText) nameField.getComponent();
    }
    return null;
  }
  public void setNameField(RichInputText nameField)
  {
    this.nameField = ComponentReference.newUIComponentReference(nameField);
  }

ComponentReference stores a path consisting of either child index positions or component ID strings, not UIComponent instances. This makes it so that always the correct component instance is accessed in each view.

Now, what I didn’t know until the aforementioned email discussion is that the above ComponentReference code should also be used with managed beans in requestScope and backingBeanScope.This is because within one request we can still navigate from one JSF view to another. If both views use a component binding by the same name, then potentially a UI component could be moved from one UI tree to another which is not allowed, and can result in unexpected behavior. This issue is vividly illustrated in the post “JSF Component Binding Stinks” by Andrew Robinson. This brings me to the first rule:

1. Always use ComponentReference binding code in your managed beans, regardless of the scope the bean is in.

Having said this, the above rule will not solve additional issues that might happen when your bean is in session scope. Session scope is shared between multiple browser tabs, so if you open the same application page in multiple browser tabs, you can run into nasty threading and concurrency issues that are explained in more detail in this old post from Blake Sullivan (the problems he mentions with ComponentReference have been solved in the meantime). Which results in the second rule:

2. Never use UIComponent binding in session-scoped managed beans.

These are the two golden rules you must apply to get a correctly working ADF-JSF application.

Now, there are additional techniques you should consider to follow best practices. Firstly, there are many situations where you can avoid the use of UIComponent binding alltogether. Duncan Mills wrote a nice blog post about the UIManager pattern which describes a design pattern to avoid component binding at all. Secondly, if you really need a handle to a UIComponent you can also lookup the component by searching the UITree. Frank Nimphius wrote ADF Code Corner sample 58 on using the invokeOnComponent API to do so. Note that if you use the invokeOnComponent API, you should start searching as low as possible in the UI component tree. Starting with the UIViewRoot component might slow down performance considerably if you have large pages with many components.  Often, you can start with the parent or grand parent component of the event component that can be retrieved from the ActionEvent argument in actionListener methods. 

As a final note, you might want to know that an enhancement request has been logged against JDeveloper to directly generate the correct ComponentReference code when using the managed bean dialog for setting the binding property on a component.

 

 

 

Understanding the JSF Lifecycle and ADF Optimized Lifecycle

While coaching ADF development teams over the years, I have noticed that many developers lack a basic understanding of Java Server Faces, in particular the JSF lifecycle and how ADF optimizes this lifecycle in specific situations. As a result, ADF developers who are tasked to build a seemingly simple ADF page, can get extremely frustrated by the -in their eyes- unexpected or unlogical behavior of ADF.  They start to play with the immediate property and the partialTriggers property in a trial-and-error manner. Often, they play with these properties until their specific issue is solved, unaware of other more severe bugs that might be introduced by the values they choose for these properties.

So, I decided to submit a presentation for the UKOUG entitled “What you need to know about JSF to be succesful with ADF”.  The abstract was accepted, and I started putting together the presentation and demo application. I built up a demo application step-by-step, trying to cover the JSF-related  top issues and challenges I encountered over the years in a simple “Hello World” demo. This turned out to be both a very time-consuming and very interesting journey. I had never thought I would learn so much myself in preparing this presentation. I never thought I would end up with potentially controversial conclusions like “Never set immediate=true on an editable component”.  I did not realize the sometimes immense implications of the ADF optimized lifecycle beforehand. I never thought that “Hello World” demo’s could get so complex. But as I went on I was confident this was valuable material, even for experienced ADF developers with a good understanding of JSF.

When I finished, I realized the original title and abstract was misleading, as was the target audience. Yes, it was covering the JSF lifecycle, but no other aspects of JSF you need to know for ADF development. Yes, it was covering some JSF basics as mentioned in the abstract, but all in all it had become a pretty advanced presentation. At the same time, the issues discussed are very common, novice ADF developers might easily run into them while building their first pages. I ran out of time, so I decided to just present what I had, apologizing at the beginning for the misleading title, showing a second slide with a better title “18 invaluable lessons about ADF-JSF interaction”. I think the presentation was well received overall, although people who don’t like it or don’t understand it, usually don’t come and tell you afterwards….

I am still struggling with the title, for this blog post I used yet another title, anyway, you can download the presentation-that-still-lacks-a-good-title here. The finished JDev 11.1.1.6 demo app can be downloaded here.  The 18 lessons mentioned in the presentation are summarized here. As mentioned on the last slide, print out the lessons, and learn them by heart, I am pretty sure it will save you lots of time and frustration!