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

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

Comments:

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

thank's

gio

Posted by Giovanni on March 10, 2014 at 04:37 PM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
21
31
     
Today