Passing User Context When Invoking ADF BC SOAP Web Services

Introduction ADF web applications often use session-scoped user context information that is also used in the ADF Business Components (ADF BC) layer. For example, the user language might be used to query language-specific data from the database. This article explains how this user context can be set up when accessing the ADF BC layer through […]

ADF-WebCenter Responsive-Adaptive Design Beyond

Introduction A topic that comes up frequently in many ATEAM customer engagements is what are the best practices for producing a responsive design for a WebCenter application. There are many informative blogs and presentations on how to achieve this through-out the web. The methodology and strategies used by the authors will often depend on the […]

Getting Portlet Queue Full Message on WebCenter Portlets

Introduction WebCenter Portal defines default parameters for portlets usage, which are very well suited for most of the cases. If the portal is under high load or performance test, portlets consumed from the portal could throw intermittently unavailable exceptions. In the portal log error message states that the queue is full and the pool is not […]

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 […]

Customizing Session Time Out Pop Ups

Introduction In past posts, ATEAM has detailed how to customize the default behavior of the out-of-the-box (OOTB) session time out popups: tips-on-dealing-with-the-session-time-out-popup how-to-create-a-custom-session-timeout-page-for-webcenter-spaces An item that has frequently been asked to ATEAM is how to customizing the default strings that are in the OOTB session time out popups. This blog post will detail the steps […]

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 […]

High availability considerations for WebCenter Portal and ADF

Introduction High availability is very important in large WebCenter installations. It allows users to gracefuly switch from one node to another node in the cluster. This allows user to keep their session in case a node goes down. In order for this to work, some conciderations need to be made when implementing a WebCenter Portal […]

Improving ADF Page Rendering Time : Progressively Loading Taskflows

Introduction On a normal ADF page with multiple task flows, each of the individual task flows need to be initialized and their initial views created before the page can render. This makes it important to consider how the page design, and task flow usage affect the page load time when designing the UI for your ADF based […]

Optimizing WebCenter Portal Mobile Delivery

Introduction Page weight and page load times are two of the most common performance metrics used to measure a Portal’s performance. These are significant factors behind a portal’s success especially in the context of mobile devices. This article walks you through identifying and analyzing some common WebCenter Portal performance bottlenecks related to page weight and […]

New ADF Architecture TV YouTube Channel Launched

The ADF Product Management team has just announced the ADF Architecture TV YouTube channel.  The channel will publish new episodes on ADF design, architecture, development and deployment best practices each week, for a total of about 100 episodes. The channel has specifically been designed with small, discrete episodes on topics encompassing the whole ADF development […]

ADF JavaScript Partitioning for Performance

Introduction ADF UI components are complex entities, each containing one or more html, css and javaScript (JS) elements. When a component is rendered the html tags are stamped on page with right css style classes attached. ADF is smart enough to download only the javaScripts belonging to the components rendered on the page. If individual […]

Adventures in WebCenter Skinning : af:table with Custom Pagination

Since the requirement on how to effectively skin a custom WebCenter Portal application frequently becomes a major topic in many of my customer egagements, I have decided to posts a series of blogs that will provide some insight on skinning some of the out-of-the-box (OOTB) ADF components.  The first component skinning example that I will cover is the ADF table. 

Most of the time when I see a custom skin implementation for a table, the code for the table is actually made up of a main header, proceeded by an iteration-type component – af:forEach or af:iterator – then proceeded by the row(s).  The actual row would be constructed as a container, which can hold other containers, that holds the record items.  This approach does make skinning the table much simpler, but there can be more components needed to construct the table itself.  Moreover, some of the OOTB af:table behavior, for example: column sorting, and filtering to name a few, will have to implemented as custom code.

The image below is how the sample table looks without any custom skining:

 

The image below is example of the same af:table with a custom skin.  Beyond the obvious look-n-feel (LnF) difference of a non-skinned table, there is also the addition of a custom pagination feature.  While the (default) scroll-bar behavior maybe acceptable for a web-based application, it is not a desirable feature for a typical web-site portal design.  In addition, in my experiences with customers on the WebCenter platform, the custom pagination behavior is one of the most requested requirements. 

Tips on Dealing with the Session Time Out Popup

During performancing tuning engagements, the ATEAM frequently recommends that the HTTP session timeout value for WebCenter custom portal applications be set to lower value (for example:10 minutes) than the out-of-the-box value of 45 minutes.  The lower number helps the server stay performant particularly during significant load.  The longer the session time, the longer the server will have to hold memory until the inactive session(s) expires.  Configuring the session timeout value is simple and can be done through the web.xml:

<session-config>
  session-timeout>10</session-timeout>
</session-config>

Once this value is set, a warning popup will appear (default) two seconds before the session is set to expire.  After the warning has expired, the final page expire message appears.

Having these messages appear are usually justified in many custom portal deployments.  However, in other custom portals, a session can equivalate to being logged in.  So in the instance of a “public” user, the appearance of these messages may not be an expected behavior.  The good news is that there is a easy configuration setting to disable these messages from appearing.  The following configuration settings in the web.xml do all of the work:

<context-param>
  <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  <param-value>client</param-value>
</context-param>

<context-param>
  <param-name>
     oracle.adf.view.rich.sessionHandling.WARNING_BEFORE_TIMEOUT
  </param-name>
    <param-value>0</param-value>
</context-param>

The STATE_SAVING_METHOD value is set to “client”, and the value correlates to value needed for a page’s af:document tag.  This tag, has the stateSaving property set to “default”, which means get the value from the context param.  Notice in the WARNING_BEFORE_TIMEOUT value has been set to 0.  Out-of-the-box, the default value is 120 seconds.  Any value less than the default will disable the popup. 

The bad news is that the setting only handles the popup.  Any subsequent page action, partial-page event, or navigation through a commandLink* will produce the unhandled ViewExpiredException (ADF_FACES-60098) in the Faces, RESTORE_VIEW, lifecycle:

* Note: For a WebCenter custom portal application the use of goLinks that use the navigation model based prettyURL as the destination is preferred.  In addition, goLinks would not have this issue.

One way of handling this would be to extend the portal application to support a custom exception handler.  In this blog post, I would like to introduce an alternative approach.

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!

Run custom JavaScript when ADF page loads

Ran into a neat way to load and run custom javascript when an ADF page loads:         <af:resource type=”javascript”>           //Script block           if (window.addEventL…

Oracle releases ADF Essentials

In case you missed it, Oracle has released a new free version of ADF called ADF Essentials.  You can find more information in the press release or the online demo.