Oracle ADF Architecture TV - Development - Programming Best Practices

1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.


Real World ADF Design & Architecture Principles ADF Programming Best Practices for Architects

ORACLE PRODUCT

LOGO

15th Feb 2013 v1.0


Learning Objectives

•  At the end of this module you should be able to: – Avoid common mistakes when building ADF applications – Understand good ADF development practices

–  Identify the patterns to develop for your ADF application

Image: imagerymajestic/ FreeDigitalPhotos.net


Secret of Oracle ADF Rockstar Programmers

"You cannot buy experience, you have to earn it" - Duncan Mills


Program Agenda

•  ADF Business Components •  ADF Binding Layer •  ADF Controller •  ADF Faces •  JavaScript •  WORA •  Use Pattern


ADF Business Components Architecture

Application Module

View Object

Entity Object

1 *

Data Model XML Definition

View Object Base Class

XML Definition

Entity Object Base Class

References References

XML Definition

AM Base Class

References


ADF Business Components Use a Layer of Framework Extension Classes

EntityImpl

YourOrgEntityImpl

YourAppEntityImpl


General Considerations

•  Always create and use custom base-classes for at least – ApplicationModuleImpl – EntiyImpl – ViewRowImpl – ViewObjectImpl

•  Note that creating custom super classes for <object>Def classes are less common

Custom Framework Extension Classes


Entity & View Object

•  Generate Java Impl files when entity objects are accessed from Java or Groovy

•  Ensure code that accesses entity objects directly uses type safe APIs instead of the generic framework APIs

•  Do not generate Impl classes without a need – Keep code base size reasonable. –  Impl classes for the *def classes are rarely needed

When to generate Java Impl files


View Criteria

•  Not necessary to create separate VO that only differ by their WHERE clause

•  Apply view criteria declaratively when defining view accessor and AM data model instances –  Use bind variables with View Criteria –  Be aware that "Ignore Null Values" options is of bad performance

•  Avoid direct user input in ADF BC queries to protect against SQL injection attacks

Prefer One View Object with Many View Criteria


View Criteria Selectively Required Option •  Prevent user from doing

"blind" query •  Typically includes your

indexed columns


General Considerations

•  Passivation occurs when the application module used by a user is passed on to another user request

•  Keep in mind that –  AM should be tuned to not passivate too often –  Java objects are not passivated

• Consider the use of transient attributes and mark them for passivation •  Alternative option: Use UserData Map in ADF BC to save information you need

for longer

Think Passivation


Program Agenda



Understanding ADF Bindings How Oracle ADF binds into JSF

Business Service ADF Data Binding

Web Service

POJO

ADF BC

EJB

JMX

TopLink

BAM UI Renderer

Component

FacesCtrl Binding

Expression Language

JSF Page Data

Control Data

Binding ADF Faces Component

Tag (<af:name../>)

Server Side JSF Component

Component Model

JUCtrl Generic Binding


Programming Against the Binding Layer

•  Expression Language – Current binding layer can be accessed from #{bindings} – Use from JSF components – Use from PageDef file

•  Java – ADF binding layer is represented by Java objects at runtime –  BindingContext.getCurrent()is the generic entry point – Binding can be accessed from UI components (for example:

af:tree -> ((CollectionModel) getValue()).getWrappedData()


Understanding ADF Binding Programming Example: Accessing the Binding Layer

import oracle.adf.model.BindingContext; import oracle.binding.BindingContainer; … BindingContext bctx = BindingContext.getCurrent(); BindingContainer bindings = null; bindings = bctx.getCurrentBindingsEntry();


Understanding ADF Binding Programming Example: Accessing Attribute Binding

AttributeBinding attributeBinding = null; attributeBinding = (attributeBinding)bindings.get("AttributeName"); /* set / get value */ attributeBinding.setInputValue(value); attributeBinding.getInputValue();


Understanding ADF Binding Programming Example: Method and Action Bindings //get method or action binding OperationBinding methodBinding = (OperationBinding)bindings.get("methodOrActionBinding"); //optional: if method expects arguments Map paramsMap = methodBinding.getParamsMap(); paramsMap.put("argumentName1",value); Object result = methodBinding.execute(); //check for errors, e.g. exceptions List errors = method.getErrors(); If(!errors.isEmpty()){ …}


Understanding ADF Binding Programming Example: Access Current Iterator Row

DCIteratorBinding dcIterBinding = (DCIteratorBinding)bindings.get("IteratorName"); Row rw = dcIterBinding.getCurrentRow(); //optional: read attribute value Object attributeValue = rw.getAttribute("AttributeName");


Typical Programming Mistakes

•  Accessing the binding context from #{data} –  Legacy code

•  Accessing the binding layer outside of JSF and ADF request cycle –  Filter in web.xml -> too early in the request cycle –  Task flow initializer / finalizer -> no associated PageDef file –  PhaseListener -> before RESTORE_VIEW causes NPE

•  "Pinning" binding reference –  Saving bindings in a property of a managed bean that is in a scope

longer than request –  Managed bean outlives binding container refresh cycle -> stale data


Typical Programming Mistakes •  Attempt to access binding that is out of scope

–  Bounded task flow in region cannot access binding container of parent view

•  Call BindingContext.getCurrent() to access ApplicationModule (AM Impl) to call method on it –  Bypasses binding layer –  Bypasses ADF error handling

•  Release binding container –  ADF framework handles binding container and iterator lifecycle. No need to

explicitly release a binding –  Cause: Legacy ADF BC coding rules

•  Fighting the framework

22 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 22 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Don't fight the framework.

Image: Ambro/ FreeDigitalPhotos.net


Program Agenda



Task Flow Oriented Design

•  Think task flow from design time on •  Think "unit-of-work" and factor task flow functionality into subflows

–  Share Data Control frame with sub-flows –  Hide sub-flows from showing in ADF library –  If you cannot fully explain and describe a task flow in 60 seconds it

probably is too big


Use Task Flow as a "Common Language"

•  Use task flow diagrammer as "common language" –  Use task flow templates as blue prints –  Use verbs and meaningful names in control flow case names

•  editOrder, createOrder, manageEmployee

•  Use the display and description properties of the contained activities to explain the non-obvious


Task Flow Design

•  Small task flows: –  Require a lot of calling and maintenance management overhead –  Reasonable sizes for distributed team development –  Provide ultimate flexibility in architecture

•  Large task flows: –  Require less calls and maintenance management overhead –  Less flexible as you can't call discrete functionality within the flow –  Memory footprint likely bigger than small task flows

Task Flow Sizing Considerations


Task Flow Design

•  Meet in the Middle –  Larger task flows built out of several smaller task flows –  Only top level task flow exposed for reuse –  Encapsulates task flow dependencies

• Good for distributing work among developers • Dependency management "by agreement" in smaller teams • Smaller memory foot print through load-on-demand and task flow

private memory scopes



Task Flow Design

•  If you save a lot of data in pageFlowScope, keep the task flow small and exit at earliest opportunity

•  Keep task flows that run in their own transaction as small as possible and exit them at earliest opportunity



Best Practices at a Glance •  Use input parameters and return values as the only API •  Document task flows with diagrammer notes •  Save task flow input parameter values in managed beans in

pageFlowScope –  Easy to document –  Type safe API –  EL accessible –  Easy to discover and manipulate task flow input values

•  Always use the smallest possible scope for managed beans •  Don't reference managed beans in session or application scope


Best Practices at a Glance

•  Use shared data control scope as often as possible –  Less database connections – Automatic parent view collection to child task flow detail collection

synchronization •  Define an exception handler activity in every bounded task flow •  Make use of Task Flow Templates

–  e.g. to define exception handlers for all bounded task flows


Best Practices at a Glance

•  Avoid cluttering diagrams for common navigation rules •  Use wild card navigation for common functionality

–  Cancel –  Commit

Wildcard Navigation



•  Trying to access parent view managed bean objects or bindings – Use object references in task flow input parameters instead

•  Use managed bean in session scope to share data – Consider shared data control or input parameters instead

•  Use managed bean in request or backing bean scope for bean that switches task flows in dynamic regions – Use at least view scope to avoid ADF binding conflicts



• Use of NavigationHandler().handleNavigation() to navigate in bounded task flows – Queue action on hidden command button –  queueActionEventInRegion on af:region


Managed Beans

•  Encapsulate all model manipulation code in custom AM and/or VO methods & invoke them declaratively – Makes your app easier to regression test

•  Only code that belongs in a JSF managed bean is… – Complex, dynamic UI component manipulation – Complex conditional navigation

•  Even if you require backing bean code, invoke custom AM or VO methods using action binding – Guarantees uniform error handling


Managed Beans

• Managed beans are lifecycle objects that are managed by the JavaServer Faces framework.

• Managed beans can extend a base class – Super class can provide common functionality as public methods

• e.g. ValueExpression, MethodExpression utility methods – Comparable to JSFUtil and ADFUtil but EL accessible

• Utility classes are typically static classes

• Recommendation: consider managed beans base classes

Base Classes


Managed Beans

•  Backing beans are managed beans with a tight association to a view –  Contains UI component references –  Usually not used with more than a single view –  Must be in request or backing bean scope

•  Backing beans are Java objects and as such –  Increase the application code base to maintain, migrate and further

develop

•  Recommendation –  Create backing beans only when the use case requires it

Backing Bean


Program Agenda



Working with managed beans is simple. However, doing it wrong gets you into trouble.

Here's an example.



UI Manager Pattern

•  Problem #1 – JSF component serialization exception –  JSF components are not serializable. –  Any attempt to bind JSF components to a bean in a scope broader

than request fails with an exception thrown

•  Problem #2 – JSF component values are not persisted in managed bean –  Persisting component value states in managed beans requires

scopes broader than request –  Values in request scope reset after each request leading to loss of

user data entry and failed value change listener invocations

Two Managed Bean Problems – One Cause


UI Manager Pattern Two Managed Bean Problems – One Solution

View Managed Bean Request Scope

component binding

Value 1 Value 2 Value 3 Value 4 Value 5

Managed Bean View Scope

value binding

ValueExpression Lookup



•  HTML and JavaServer Faces are different technologies –  Markup oriented vs. component oriented –  Compile – Render, vs. multi stop request lifecycle

•  Facelets in JSF 2.x support mixing of HTML and JavaServer Faces components –  Prior to Facelets and JSF 2.x, mixing HTML and JSF is a no-go –  Still with JSF 2.0 problems may occur because ADF Faces components come

with their own sizing behavior (geometry management) –  Adding HTML to the body of a JSF or ADF Faces component may break

component functionality

•  Recommendation: Build pages and views with ADF Faces components

Mixing HTML and JSF components



•  inlineStyle property allows developers to add CSS to a component rendering –  CSS is applied to top-level DOM component –  CSS is directly added to the page output –  Recommendation: Use ADF Faces skinning and reduce the use of CSS

to the absolute minimum (e.g. conditional color coding)

•  contentStyle property allows developers to add CSS to the value content area of an ADF Faces component –  Styles component content area better than inlineStyle but has same

issued as mentioned above

Use of inlineStyle and contentStyle CSS



•  ADF PageDef file is not aware of ui:include or jsp:include references in a view –  Included fragments fail at runtime if they use ADF bound components –  You can copy ADF bindings used by the included content into the view's

PageDef file. •  Prevents reuse of the fragments

•  Recommendation –  Use ui:include and jps:include for layouts only (if at all) –  Use ADF regions to add ADF bound content to a page at runtime

ui:include and jsp:include


Program Agenda



JavaScript in ADF Faces is a fair option to use. Here are the rules

1.  Know what you do and why you do it

2.  Understand the ADF Faces client side JavaScript framework

3.  Use JavaScript by exception



ADF Faces Client JavaScript Architecture

Label1 Label2 Label3

DOM

Peer Objects

Document

UI Components

Servlet

JSF Lifecycle

Component Tree

View Root

Form

Renderer

OK

Form

Form

UI Components

Server Side Client Side



•  JavaScript component API •  af:clientListener

–  Listens to DOM and ADF Faces component events •  af:serverListener

– XMLHttp JavaScript call to server – Queued as custom event on client – Answered by managed bean

•  ExtendedRenderKitService –  Trinidad class to invoke JavaScript from Java

Features



•  Component oriented API •  Integrated with JavaServer Faces and ADF Faces request lifecycle •  Ensures JavaScript calls to work on all ADF Faces certified

browsers •  Ability to listen to component events like query, selection, popup

launch etc. •  Allows you to suppress component events from propagating to the

server •  Easier to learn and deal with than vanilla JavaScript programming

Benefits


Typical JavaScript Programmer Mistakes •  Access the browser DOM tree when coding with JavaScript in ADF

Faces – DOM tree does work against generated HTML and not against

components •  Use or manipulate objects ending with "Peer"

– Use ADF Faces public APIs only: AdfRich<component name> •  Use of methods that are all upper case or camel case with a

uppercase first letter –  These methods are for internal use only

•  Use of objects in JS packages that have the name "internal" in them


Typical JavaScript Programmer Mistakes

•  Think that using JavaScript saves you a round trip –  JSF to work properly requires the server side component state to

be synchronized with the client – Suppress server round trips only if no component state has been

changed on the client


Program Agenda



Secret of Oracle ADF Rockstar Programmers

Write once reuse anywhere


Problems Addressed Through Reuse

•  Duplicate code lines –  Time spent in development –  Inconsistent implementation –  Increase of error surface – Hard to manage and change

•  Development skills – More people to skill on various technologies – Difficult to implement "expert culture”


What to Reuse ?

•  Solutions – Bounded task flows

•  Simplifications – Custom ADF frameworks that hide complexity from the

application developer – Example:

• PL/SQL integration framework • Use of contextual events • Specific page and page fragment layouts


Reusability in ADF

•  Instead of writing Java code tailored to a particular need, consider the possibility of generalizing the code, pushing it up to a custom framework class, allowing declarative customization of specific cases

•  Extra up-front investment –  Generic code is harder to write than code for a point solution –  Use Custom properties in ADF BC –  Use Managed Properties for Managed Beans –  Use helper classes (utilities)

The Methodology


Don't Worship Reuse For The Sake Of It

•  Reuse should not be an infinite ideal - be practical •  Think of “dependency firewalls” to partition solutions •  Create dependencies in a defined and controlled environment •  Independent components should not be impacted by changes to

siblings


Flogging a Dead Horse

•  It can be hard to tune the business’s mindset to software reuse – Users/analysts won’t respect that a

BTF/component used in different screens can’t be different

•  Revisit your architecture to see if something initially defined as reusable just isn’t practical

Image: msuicdragon / photobucket


Program Agenda



Surprise, Surprise !

Look mum, wheels! They exist.


Use Pattern: Summary

•  Patterns are popular –  Blueprint of a solution to a problem

•  Good practices –  Identify pattern for your application

•  Layout, Functionality, Navigation etc. –  Look at existing patterns that exist for Java EE, Mobile, Layout and

Usability

•  Very good practices –  Don't reinvent the wheel


Conclusion

•  Gain experience •  Learn from other people

–  OTN JDeveloper forum •  http://forums.oracle.com/forums/forum.jspa?forumID=83

–  ADF Enterprise Methodology Group (EMG) •  https://groups.google.com/forum/?fromgroups#!forum/adf-methodology

•  Read blogs –  https://pinboard.in/u:OracleADF/

•  Blog your experience


Further Reading

•  ADF Architecture Square –  http://www.oracle.com/technetwork/developer-tools/adf/learnmore/

adfarchitect-1639592.html

•  Oracle ADF Functional Patterns and Best Practices –  http://www.oracle.com/technetwork/developer-tools/adf/index-100668.html

•  Whitepaper: An Introduction to ADF Best Practices –  http://www.oracle.com/technetwork/developer-tools/jdev/introduction-best-

practices-131743.pdf

•  Book: Oracle ADF Real World Developer's Guide –  http://www.packtpub.com/oracle-application-development-framework-real-world-developers-

guide/book


Date post:	11-Nov-2014
Category:	Technology
Upload:	chris-muir
View:	290 times
Download:	0 times

Oracle ADF Architecture TV - Development - Programming Best Practices

Technology