Developer Partner Community

  • March 10, 2014

ADF Classic mistakes and Worst practices (abstract from UKOUG 2013) by Amis

Juergen Kress
PaaS Partner Adoption

The UKOUG Technology conference in Manchester hosted several very interesting sessions regarding ADF best and worst practices. Some slides are publicly available (see links at the bottom of this blog) but since there where multiple session and speakers I decided to write this blog post and share with you the most prominent do’s and don’t that might even surprise a skillful ADF developer. The topics covered below are certainly not all-encompassing, because one could write a whole book about it, but it does show some topics that may make your say “I wish I had known this a year ago”.

1. Do not prefix all managed bean EL expression with a specific scope.

In some cases, being over explicit is a bad thing when referencing managed beans in EL, for example #{requestScope.beanName.propertyName}.

Never prefix in case of default Servlet scope, meaning requestScope, sessionScope and applicationScope. By prefixing the scope you bypass the JavaServer Faces managed bean facility. This means it will only look for in-memory objects and does not instantiate managed beans (causing an NPE).

Do prefix in case of ADF specific scope e.g. backingBeanScope, viewScope and pageFlowScope. These are handled by the ADF controller (instead of the standard servlet mechanism) and it takes care of managed bean instantiation (if configuration is available).

In general, you should try to avoid using the default servlet scopes all together and always use the smallest scope possible (this minimizes memory usage). In regards to requestScope and backingBeanScope, note that the backingBeanScope is basically the same as requestScope but when you add the same taskflow twice on one page, they will each have their own backingBeanScope. This is not the case when using request scope!

SessionScope is most suited for storing user context information (e.g. name etc.), do not use sessionScope to pass/reuse values between taskflows, but use TF parameters instead. Also keep in mind that all sessionScope data is shared across browser tabs.

2. Never set immediate=true on an editable components

The most common use case for the immediate property is implementing Cancel/Reset functionality on input forms. In this situation you want to ‘skip’ validation and this is simply achieved by setting the immediate=true property on the commandbutton component, which is fine.

The immediate=true property can also be set on input components such as af:inputText, but this should be avoided whenever possible. You will most likely end up with a page that can never be navigated away from. To fully understand the rationality behind this you must know your ADF lifecycle and ADF optimized lifecycle. I can highly recommend reading this post of Steven Davelaar and his demo-app explaining the JSF/ADF life-cycle. Read the complete article here.

WebLogic Partner Community

For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Mix Forum Wiki

Join the discussion

Comments ( 1 )
  • Giovanni Monday, March 10, 2014

    good article but,
    would also be useful to bring same examples



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.