| Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers 10g Release 3 (10.1.3.0) Part Number B25947-02 |
|
|
View PDF |
| Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers 10g Release 3 (10.1.3.0) Part Number B25947-02 |
|
|
View PDF |
This chapter describes the architecture and key functionality of the Oracle Application Development Framework (Oracle ADF).
This chapter includes the following sections:
Section 1.2, "Framework Architecture and Supported Technologies"
Section 1.3, "Declarative Development with Oracle ADF and JavaServer Faces"
The Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on J2EE standards and open-source technologies to simplify and accelerate implementing service-oriented applications. If you develop enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces, Oracle ADF can simplify your job. Used in tandem, Oracle JDeveloper 10g and Oracle ADF give you an environment that covers the full development lifecycle from design to deployment, with drag-and-drop data binding, visual UI design, and team development features built-in.
In line with community best practices, applications you build using Oracle ADF achieve a clean separation of business logic, page navigation, and user interface by adhering to a model, view, controller architecture. As shown in Figure 1-1, in an MVC architecture:
The model layer represents the data values related to the current page
The view layer contains the UI pages used to view/modify that data
The controller layer processes user input and determines page navigation
The business service layer handles data access and encapsulates business logic
Figure 1-2 illustrates where each ADF module fits in this architecture. The core module in the framework is Oracle ADF Model, a declarative data binding facility that implements the JSR-227 specification. The Oracle ADF Model layer enables a unified approach to bind any user interface to any business service with no code. The other modules Oracle ADF comprises are:
Oracle ADF Business Components, which simplifies building business services for developers familiar with 4GL tools like Oracle Forms, PeopleTools, SiebelTools, Visual Studio, and others
Oracle ADF Faces, which offers a rich library of UI components for web applications built with JavaServer Faces (JSF)
Oracle ADF Swing, which extends Oracle ADF Model to desktop applications built with Swing
Oracle ADF Controller, which integrates Struts and JSF with Oracle ADF Model
In the view layer of your application, where you design the web user interface, you can develop using either classic JavaServer Pages (JSP) or the latest JavaServer Faces (JSF) standard. Alternatively, you can choose the polish and interactivity of a desktop UI, and develop using any off-the-shelf Swing components or libraries to ensure just the look and feel you need. Whatever your choice, you work with WYSIWYG visual designers and drag-and-drop data binding. One compelling reason to choose JSF is the comprehensive library of nearly one hundred JSF components that the ADF Faces module provides.
ADF Faces components include sophisticated features like look and feel "skinning" and the ability to incrementally update only the bits of the page that have changed using the latest AJAX programming techniques. The component library supports multiple JSF render kits to allow interfacing with web browsers and PDA telnet devices. In short, these components dramatically simplify building highly attractive and functional web and wireless UIs without getting your hands "dirty" with HTML and JavaScript.
In the controller layer, where handling page flow of your web applications is a key concern, Oracle ADF integrates both with the popular Apache Struts framework and the built-in page navigation functionality included in JSF. In either case, JDeveloper offers visual page flow diagrammers to design your page flow, and the ADF Controller module provides appropriate plug-ins to integrate the ADF Model data binding facility with the controller layer's page processing lifecycle.
In the model layer, Oracle ADF Model implements the JSR-227 service abstraction called the data control and provides out-of-box data control implementations for the most common business service technologies. Whichever ones you employ, JDeveloper and Oracle ADF work together to provide you a declarative, drag-and-drop data binding experience as you build your user interfaces. Supported technologies include:
ADF application modules
These service components expose an updateable dataset of SQL query results with automatic business rules enforcement.
Web Services
When the services your application requires expose standard web services interfaces, just supply Oracle ADF with the URL to the relevant Web Services Description Language (WSDL) for the service endpoints and begin building user interfaces that interact with them and present their results.
XML
If your application needs to interact with XML or comma-separated values (CSV) data that is not exposed as a web service, you need only supply the provider URL and optional parameters and you can work with the data.
JavaBeans and Enterprise JavaBeans (EJB) Session Beans
When necessary, you can easily work with any Java-based service classes as well, including EJBs that support transactions.
For enterprise 4GL developers building new web applications, Oracle recommends using JavaServer Faces for the view and controller layers, and ADF Business Components for the business service implementation. This combination offers you the same productive J2EE technology stack that over 4000 of Oracle's own enterprise 4GL developers use every day to build the Oracle E-Business Suite. Since its initial release in 1999, several thousand external customers and partners have built and deployed successful Oracle ADF-based applications as well. Both now and in the future, Oracle and others are betting their business on Oracle ADF with ADF Business Components.
Even as a seasoned user of rapid application development tools like Oracle Forms, PeopleTools, SiebelTools, or Visual Basic, you've likely already had some exposure to Java 2 Enterprise Edition. Maybe your interest in J2EE began as it did for Oracle's own E-Business Suite division, while evaluating standards-based architectures for self-service web applications to complement traditional desktop UIs for professional users. Or perhaps you've simply been studying in your spare time to expand your skill set and reinforce your resume.
Whatever your point of departure, initial impressions of your J2EE experience probably parallel those of fellow 4GL users. You understand how J2EE can increase flexibility, reuse, and choice, but its many "moving parts" leave you a little puzzled. Accustomed to banging out screen after screen with your familiar 4GL tools, you fear it's more likely your head you'll be banging if you have to write all that J2EE code by hand. You'll be glad to learn that all of the 4GL features you are familiar with have an analog in JDeveloper 10g with Oracle ADF, including:
Declarative data access and validation
Declarative user interface design and page navigation
Declarative data binding
Simple, event-driven approach to add custom logic where needed
When you use Oracle ADF's XML- and Java-based declarative development facilities in Oracle JDeveloper 10g, you also benefit from design-time error highlighting, context-sensitive editing assistance, and compile-time error checking.
When building service-oriented J2EE applications, you implement your core business logic as one or more business services. These backend services provide clients a way to query, insert, update, and delete business data as required while enforcing appropriate business rules. ADF Business Components are prebuilt application objects that accelerate the job of delivering and maintaining high performance, richly-functional, data-centric services. They provide you a ready-to-use implementation of all the J2EE design patterns and best practices that Oracle's own application developers have found are needed to do the job right. By leveraging this road-tested code, you focus on your own application-specific logic instead of reinventing the wheel.
As illustrated in Figure 1-3, Oracle ADF provides the following key components to simplify building database-centric business services:
Entity object
An entity object represents a row in a database table and simplifies modifying its data by handling all DML operations for you. It can encapsulate business logic for the row to ensure your business rules are consistently enforced. You associate an entity object with others to reflect relationships in the underlying database schema to create a layer of business domain objects to reuse in multiple applications.
Application module
An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.
View object
A view object represents a SQL query and simplifies working with its results. You use the full power of the familiar SQL language to join, project, filter, sort, and aggregate data into exactly the "shape" required by the end-user task at hand. This includes the ability to link a view object with others to create master/detail hierarchies of any complexity. When end users modify data in the user interface, your view objects collaborate with entity objects to consistently validate and save the changes.
Tip:
Oracle Forms developers will immediately recognize this combined functionality as the same set of data-centric features provided by the form, data blocks, record manager, and form-level procedures/functions. The key difference in ADF is that the user interface is cleanly separated from data access and validation functionality. For more information, see Section 4.3.1, "Familiar Concepts for Oracle Forms Developers"JavaServer Faces simplifies building web user interfaces by introducing web UI components that have attributes, events, and a consistent runtime API. Instead of wading knee-high through tags and script, you assemble web pages from libraries of off-the-shelf, data-aware components that adhere to the JSF standard.
The industry experts who collaborated on the JavaServer Faces standard incorporated numerous declarative development techniques into the design. For example, in JSF you use a simple expression language to work with the information you want to present. Example expressions look like #{UserList.selectedUsers} to reference a set of selected users, #{user.name} to reference a particular user's name, or #{user.role == 'manager'} to evaluate whether a user is a manager or not. At runtime, a generic expression evaluator returns the List, String, and boolean value of these respective expressions, automating access to the individual objects and their properties without requiring code. This declarative expression language, nicknamed "EL," originally debuted as part of the JSTL tag library and an improved version is now incorporated in the current JSP and JSF standards.
At runtime, the value of a JSF UI component is determined by its value attribute. While a component can have static text as its value, typically the value attribute will contain an EL expression that the runtime infrastructure evaluates to determine what data to display. For example, an outputText component that displays the name of the currently logged-in user might have its value attribute set to the expression #{UserInfo.name}. Since any attribute of a component can be assigned a value using an EL expression, it's easy to build dynamic, data-driven user interfaces. For example, you could hide a component when a set of objects you need to display is empty by using a boolean-valued expression like #{not empty UserList.selectedUsers} in the UI component's rendered attribute. If the list of selected users in the object named UserList is empty, the rendered attribute evaluates to false and the component disappears from the page.
To simplify maintenance of controller-layer application logic, JSF offers a declarative object creation mechanism. To use it, you configure the Java objects you need to use in a JSF faces-config.xml file. These objects are known as managed beans since they have properties that follow the JavaBeans specification and since the JSF runtime manages instantiating them on demand when any EL expression references them for the first time. JSF also offers a declarative mechanism to set the properties of these beans as they are first created. Managed beans can have managed properties whose runtime value is assigned by the JSF runtime based on a developer-supplied EL expression. Managed properties can depend on other beans that, in turn, also have managed properties of their own, and the JSF runtime will guarantee that the "tree" of related beans is created in the proper order.
Figure 1-4 shows how JSF managed beans serve two primary roles.
Request-scoped managed beans that are tightly related to a given page are known colloquially as backing beans, since they support the page at runtime with properties and methods. The relationship between a UI component in the page and the backing bean properties and methods is established by EL expressions in appropriate attributes of the component like:
value="#{expr}"
References a property with data to display or modify
action="#{expr}"
References a method to handle events
binding="#{expr}"
References a property holding a corresponding instance of the UI component that you need to manipulate programmatically — show/hide, change color, and so on.
Think of managed beans that aren't playing the role of a page's backing bean simply as "application logic beans." They contain code and properties that are not specific to a single page. While not restricted to this purpose, they sometimes function as business service wrappers to cache method results in the controller layer beyond a single request and to centralize pre- or post-processing of business service methods that might be used from multiple pages.
In addition to using managed beans, you can also write application code in a PhaseListener class to augment any of the standard processing phases involved in handling a request for a JSF page. These standard steps that the JSF runtime goes through for each page are known as the "lifecycle" of the page. Most real-world JSF applications will end up customizing the lifecycle by implementing a custom phase listener of some kind, typically in order to perform tasks like preparing model data for rendering when a page initially displays.
In addition to declarative UI design, JSF also provides a mechanism to declaratively define page navigation rules. Developers define these rules by specifying logical names for the legal navigation "outcomes" of a user's interaction with a page. For example, while on a UserDetails.jspx page modifying details of an account, an end user may interact with the page by clicking a Save button. The logical navigation outcomes of this interaction might be to go to a MoreDetails.jspx page to see more details, or else go back to a BrowseUsers.jspx page to see a list of user accounts. As shown in Figure 1-5, you might pick names like GotoMoreDetailsPage and BackToBrowsePage to describe these two outcomes. The navigation rule information is saved along with other configuration information in the faces-config.xml file, and at runtime JSF handles the page navigation based on these logical outcome names.
The Oracle ADF Model layer uses XML configuration files to drive generic data binding features. It implements the two concepts in JSR-227 that enable decoupling the user interface technology from the business service implementation: data controls and declarative bindings.
Data controls abstract the implementation technology of a business service by using standard metadata interfaces to describe the service's operations and data collections, including information about the properties, methods, and types involved. At design time, visual tools like JDeveloper can leverage the standard service metadata to simplify binding UI components to any data control operation or data collection. At runtime, the generic Oracle ADF Model layer reads the information describing your data controls and bindings from appropriate XML files and implements the two-way "wiring" that connects your user interface to your business service. This combination enables three key benefits:
You write less code, so there are fewer lines to test and debug.
You work the same way with any UI and business service technologies.
You gain useful runtime features that you don't have to code yourself.
Declarative bindings abstract the details of accessing data from data collections in a data control and of invoking its operations. There are three basic kinds of declarative binding objects that automate the key aspects of data binding that all enterprise applications require:
Iterator bindings to bind to an iterator that tracks the current row in a data collection
Value bindings to connect UI components to attributes in a data collection
Action bindings to invoke custom or built-it operations on a data control or its data collections
Iterator bindings simplify building user interfaces that allow scrolling and paging through collections of data and drilling-down from summary to detail information. UI components that display data use value bindings. Value bindings range from the most basic variety that work with a simple text field to more sophisticated list, table, and tree bindings that support the additional needs of list, table, and tree UI controls. An action binding is used by UI components like hyperlinks or buttons to invoke built-in or custom operations on data collections or a data control without writing code.
Figure 1-6 illustrates the architecture of a JSF application when you leverage ADF Model for declarative data binding. By combining Oracle ADF Model with JavaServer Faces, you avoid having to write a lot of the typical managed bean code (shown above in Figure 1-4) that would be required for real-world applications.
In fact, many pages you build won't require a backing bean at all, unless you perform programmatic controller logic that can't be handled by a built-in action or service method invocation (which ADF Model can do without code for you). You can also avoid having to write any application logic beans that wrap your business service, since the ADF Model's data control implements this functionality for you. And finally, you can often avoid the need to write any custom JSF phase listeners because ADF Model offers a generic JSF phase listener that performs most of the common operations you need in a declarative way based on information in your page definition metadata.
Oracle ADF provides you a lot of declarative functionality and spares you from having to master and implement all the J2EE design patterns required for enterprise J2EE applications. The Java code you do write, as has always been the case in your familiar 4GL tools, is only the code that's unique to your specific business application or user interface interactions. The web-based applications you'll build using Oracle ADF have a cleanly layered architecture consisting of:
JSF pages with UI components in the view layer
JSF backing beans containing UI event handling and page flow logic in the controller layer
ADF Model declarative data binding in model layer
ADF Business Components implementing data access and validation in the business services layer
In practice, since the UI components are represented as nested tags in a JSP page, and declarative bindings are captured in the XML page definition file, the two layers in which you will write application-specific code are the controller layer and the business services layer.
When the end user interacts with JSF UI components in the browser, they raise events you can handle. For example, the user might:
Click on a button or a hyperlink
Change the selection in a dropdown list
Expand or collapse a level in a tree display
You can write event-handling code in a JSF backing bean for a page that is triggered when these kind of UI events occur. These event handlers will look like the following:
Example 1-1 Handling a button click event in a backing bean
public String saveButton_onClick() {
// Add event code here...
if (userRequiresMoreDetailsPage()) {
return "GotoMoreDetailsPage";
else {
return "BackToBrowsePage";
}
}
Example 1-2 Handling a dropdown list's value change event in a backing bean
public void roleList_onListChanged(ValueChangeEvent event) {
// Add event code here...
}
Example 1-3 Handling a tree control's expand/collapse event in a backing bean
public void mgmtChainTree_onExpandCollapse(DisclosureEvent event) {
// Add event code here...
}
Tip:
These three JSF event handling methods are similar to the UI-related triggers in Oracle Forms namedWHEN-BUTTON-PRESSED, WHEN-LIST-CHANGED, and WHEN-TREE-NODE-EXPANDED respectively.The code you add inside these methods gets automatically triggered by the JSF runtime to handle the event when the user interacts with the related UI component. They will typically contain code that manipulates UI components on the page — hiding/showing them, changing colors, and so on — or that performs conditional page navigation logic. Should you want to handle some logic completely in the browser client, in addition to server-side JSF event-handling code, you can associate client-side JavaScript with UI components as well.
When the user works with data in the UI, the ADF Model layer coordinates any changes with the appropriate data collection in the data control. For example, in a web-based customer service portal application like the one you'll study in this guide, end-users of the system with different roles might:
Create a new service request to ask for assistance in resolving a problem
Update a service request to assign it to a new technician
Try to delete a service request
In response to these events, your business requirements might demand that:
The request date of the service request be defaulted to the current time, rounded to the nearest ten-minute interval
An appropriate technician be assigned based on availability and area of expertise when the service request is first saved to the database
A technician assignment is validated to ensure that the technician has the appropriate expertise to work on the current request
Only managers are allowed to delete a service request
Regardless of which view object the end user's action affects, if it relates to data from the SERVICE_REQUESTS table, then your central ServiceRequest entity object handles the validation and saving of those changes. The event handling code that you might write in this entity object's custom Java class get triggered at the appropriate time. These event handlers will look something like this:
Example 1-4 Handing the create event in an entity object
protected void create(AttributeList attrs) {
// First perform the default "built-in" functionality
super.create(attrs);
// Add custom creation-time defaulting logic here...
// Default the request date to the current date
setRequestDate(currentTimeRoundedToNearestTenMinutes());
}
Example 1-5 Handling the DML event for INSERT in an entity object
protected void prepareForDML(int operation, TransactionEvent event) {
// First perform the default "built-in" functionality
super.prepareForDML(operation, event);
// If we're doing an INSERT, then default the technican id
if (operation == DML_INSERT) {
// Auto-assign the new service request
setAssignedTo(determineDefaultTechnicianId());
}
}
Example 1-6 Handling an attribute validation event for AssignedTo
public boolean validateAssignedTo(Number newTechnicianId) {
// Add custom validation code here for AssignedTo attribute
// return true if valid, and false if not.
return doesTechnicianHaveAppropriateExpertise(newTechnicianId);
}
Example 1-7 Handling the remove event for an entity object
public void remove() {
// Add custom remove-time logic here...
if (isUserAllowedToDeleteRequest() == false) {
throw new JboException("You aren't allowed to remove a service request.");
}
super.remove();
}
Tip:
These four event handler methods are similar to the data-related triggers in Oracle Forms namedWHEN-CREATE-RECORD, PRE-INSERT, WHEN-VALIDATE-ITEM, and WHEN-REMOVE-RECORD respectively.To ensure modular and encapsulated code, the helper functions called by these sample event handlers like currentTimeRoundedToNearestTenMinutes(), determineDefaultTechnicianId(), doesTechnicianHaveAppropriateExpertise(), and isUserAllowedToDeleteRequest() are written as private methods in the same entity object class.
Since all of Oracle ADF is implemented itself in Java, it's not only possible but quite straightforward to extend the basic functionality of the framework or globally change the default behavior to be more like what your organization needs. In other words, rather than waiting for Oracle to implement your favorite enhancement request, you can just implement it yourself in a class that extends the appropriate base ADF class.
Consider the example above of defaulting a Date attribute to the current time rounded to the nearest ten minutes. The create() event handler method is what you would write when you encounter the first entity object that requires this functionality during your development. However, if you discover over time that your application is requiring this facility in many different entity objects, you can choose to globally add a new feature to the entity object base class. Example 1-8 shows a custom OurCompanyEntityImpl class that extends the base ADF entity object class (EntityImpl) and overrides the same create() event handling method, but this time in a global way.
After calling the super.create() method to perform the default functionality, the code performs the following steps:
Loop over all attribute definitions for this entity row.
If the type of an attribute is Date and a custom property named TenMinuteDate has been set on it by the developer, default the attribute value to the current time rounded to nearest 10 minutes.
Example 1-8 Extending the Oracle ADF Entity Object with a New Feature of Your Own
package com.yourcompany.fwkext;
public class OurCompanyEntityImpl extends EntityImpl {
protected void create(AttributeList attrs) {
super.create(attrs); // First perform the default "built-in" functionality
// 1. Then loop over all attribute definitions for this entity row
for (AttributeDef attr : getEntityDef().getAttributeDefs()) {
// 2. If attr is a Date and "TenMinuteDate" custom property is set
if (attr.getJavaType().equals(Date.class)
&& attr.getProperty("TenMinuteDate") != null) {
// 3. Default attr value to current time rounded to nearest 10 min
setAttribute(attr.getIndex(),currentTimeRoundedToNearestTenMinutes());
}
}
}
}
This is an example in the business service layer, but you can perform similar kinds of global framework customizations in virtually any layer of the Oracle ADF architecture. In practice, most Oracle ADF customers create themselves a layer of classes that extend each of the base ADF classes, then they configure Oracle JDeveloper to use their customized framework base classes instead of the ADF default class names. By doing this once, it becomes a "set it and forget it" policy that JDeveloper enforces for you as you use all of the Oracle ADF editors. Even if you initially have no need to extend the framework, just setting up the layer of framework extension classes puts you in the position to add code to those classes at any time — to work around a bug you encounter, or to implement a new or augmented framework feature — without having to revisit all of your existing applications.
Note:
Full source for Oracle ADF is available to supported customers through Oracle Worldwide Support. The full source code for the framework can be an important tool to assisting you in diagnosing problems and in correctly extending the base framework functionality for your needs.ADF has additional functionality that can greatly improve your development productivity. These features include:
Section 1.4.1, "Comprehensive JDeveloper Design-Time Support"
Section 1.4.2, "Sophisticated AJAX-Style Web Pages Without Coding"
Section 1.4.4, "Generation of Complete Web Tier Using Oracle JHeadstart"
The Studio Edition of JDeveloper includes all of the following facilities that simplify development of enterprise solutions using Oracle ADF and JavaServer Faces:
Facilities for Business Services Development
Business Components wizards and editors
Quickly create and modify the components that comprise your business services using productive wizards and editors. Reverse-engineer components from existing tables. Synchronize your components with changes that you (or the DBA) have made to the underlying database schema.
Business Components Browser
Interactively test your business service's data model even before you build a user interface. The Business Components Browser can also help isolate where problems in your application occur, as it runs your data model without running your user interface.
Business Components Diagrammer
Visualize, create, or modify your business service and business domain layer components using UML diagrams. Publish the diagrams to numerous formats for reference or inclusion in system documentation.
Facilities for Declarative Data Binding
Data control wizards
ADF application modules are automatically exposed as data controls. Should your needs call for working with web services, XML or CSV data from a URL, JavaBeans, or EJB session beans, handy data control wizards guide you step by step.
Data Control Palette
Visualize all application modules and other business services and drag their data collections, properties, methods, method parameters, and method results to create appropriate bound user interface elements. Easily create read-only and editable forms, tables, master/detail displays, and individual bound UI components including single and multiselect lists, checkboxes, radio groups, and so on. Creating search forms, data creation pages, and parameter forms for invoking methods is just as easy. If your process involves collaboration with page designers in another team, you can drop attributes onto existing components on the page to bind them after the fact. In addition to the UI components created, appropriate declarative bindings are created and configured for you in the page definition file with robust undo support so that you can modify your user interface with confidence that your bindings and UI components will stay in sync.
Page Definition Editor
Visualize page definition metadata in the Structure window and configure declarative binding properties using the appropriate editor or the Property Inspector. Create new bindings by inserting them into the structure where desired. Edit binding metadata with context-sensitive, XML schema-driven assistance on the structure and valid values.
Service method invocation
Configure business service method invocations with EL expression-based parameter passing. You can have methods invoked by the click of a command component like a link or button, or configure your page definition to automatically invoke the method at an appropriate phase of the JSF lifecycle
Page lifecycle control
Declaratively configure an iterator binding to refresh its data during a specific JSF lifecycle phase, and optionally provide a conditional EL expression for finer control over when that refresh is desired. You have the same control over when any automatic method invocation should invoke its method as well.
Centralized error reporting
Customize the error reporting approach for your application in a single point instead of on each page.
Facilities for Visual Web Page Design
Visual Web Page Designer
Design your web pages visually using the visual web page designer. The designer is integrated with the Data Control Palette to support both drag and drop creation of user interfaces, and UI-first page design with subsequent data binding applied to an initial page mockup. The visual editor supports both JavaServer Faces and traditional JSP development.
Page Flow Diagrammer
Design your web page navigation visually using the visual page flow diagram. The diagrammer supports both JavaServer Faces as well as Apache Struts.
Facilities for Visual Design for Desktop-Fidelity UI's with Swing
Visual Form Designer
JDeveloper fully supports developing desktop-fidelity user interfaces using Forms and Panels that use the standard Swing controls provided as part of Java itself. All of the Oracle ADF declarative data binding and ADF Business Components facilities work to make building either client/server or three-tier Swing applications easy.
Note:
This edition of the developer's guide focuses exclusively on Web development with JSF. The development of desktop-fidelity user interfaces using Oracle ADF and ADF Swing will be covered in a separate, follow-on developer's guide dedicated to that subject.The JSF reference implementation provides a bare-bones set of basic UI components which includes basic HTML input field types and a simple table display, but these won't take you very far when building real-world applications. The ADF Model layer implements several features that work hand-in-hand with the more sophisticated UI components in the Oracle ADF Faces library to make quick work of the rich functionality your end users crave, including:
Declarative partial page refreshing for interactive UIs
For any UI component in your pages, you can indicate declaratively which other components should trigger its being "repainted" with fresh data without causing the entire browser page to refresh. This type of more interactive web experience is known popularly as "Web 2.0" or "AJAX"-style pages.
Sophisticated table model
Tables are a critical element of enterprise application UIs. By default, JSF doesn't support paging or sorting in tables. The ADF Faces table and the ADF Model table binding cooperate to display pageable, editable or read-only, tables with sorting on any column.
Key-based current selection tracking
One of the most common tasks of web user interfaces is presenting lists of information and allowing the user to scroll through them or to select one or more entries in the list. The ADF Model iterator binding simplifies tracking the selected row in a robust way, using row keys instead of relying on positional indicators that can change when data is refreshed. In concert with the ADF Faces table and multiselection components, it's easy to work with single or multiple selections, and build screens that navigate master/detail information.
Declarative hierarchical tree components and grids
Much of the information in enterprise applications is hierarchical, but JSF doesn't support displaying or manipulating hierarchical data out of the box. The ADF Model layer provides hierarchical bindings that you can configure declaratively and use with the ADF Faces tree or hierarchical grid components to implement interactive user interfaces that present data in the most intuitive way to your users.
Flexible models for common UI components
Even simple components like the checkbox can be improved upon. By default, JSF supports binding a checkbox only to boolean properties. ADF Model adds the ability to map the checkbox to any combination of true or valid values your data may present. List components are another area where ADF Model excels. The valid values for the list can come from any data collection in a data control and the list can perform updates or be used for row navigation, depending on your needs. The ADF Model list binding also makes null-handling easy by optionally adding a translatable "<No Selection>" choice to the list.
Oracle ADF improves the reuse of several aspects of application functionality by allowing you to associate layered metadata with either your ADF Business Components or, for other data control types, the data control structure definitions that describe the data collections. These can then be reused by any page presenting their information. Examples of this functionality are:
Easily localizable prompts, tooltips, and format masks
JSF supports a simple mechanism to reference translatable strings in resource bundles, but it has no knowledge of what the strings are used for and no way to associate the strings with specific business domain objects. ADF Business Components improves on this by allowing your JSF pages to reference translatable prompts, tooltips, and format masks that you can associate with any attribute of any entity object or view object component. In this way, data is presented in a consistent, locale-sensitive way on every page where it appears.
Declarative validation
JSF supports validators that can be associated with a UI component. These offer the ability to perform basic syntactic checks on the data value. However, JSF offers no mechanism to simplify enterprise, database-centric validation nor to easily validate the same business domain data in a consistent way on every screen where it's used. ADF Business Components improves on this by allowing you to associate an extensible set of validator objects with your entity objects, and supplement that with validation code you write in event handlers as shown in Section 1.3.4, "Simple, Event-Driven Approach to Add Custom Logic". In this way, the validations are enforced consistently, regardless of which page the user employs to enter or modify the object's data.
Declarative security
JSF has no mechanism for integrating authorization information with UI components. With ADF Business Components, you can associate user or role authorization information with each attribute in an entity object so that your JSF pages can easily display data only to users authorized to see it.
As you'll learn throughout the rest of this guide, Oracle JDeveloper 10g and Oracle ADF give you a productive, visual environment for building richly functional, database-centric J2EE applications with a maximally declarative development experience. However, if you are used to working with tools like Oracle Designer that offer complete user interface generation based on a higher-level application structure definition, you may be looking for a similar facility for your J2EE development. If so, then the Oracle JHeadstart 10g application generator may be of interest to you. It is an additional extension for JDeveloper that stands on the shoulders of Oracle ADF's built-in features to offer complete web-tier generation for your application modules. Starting with the data model you've designed for your ADF business service, you use the integrated editors JHeadstart adds to the JDeveloper environment to iteratively refine a higher-level application structure definition. This controls the functionality and organization of the view objects' information in your generated web user interface. By checking boxes and choosing various options from dropdown lists, you describe a logical hierarchy of pages that can include multiple styles of search regions, List of Values (LOVs) with validation, shuttle controls, nested tables, and other features. These declarative choices use terminology familiar to Oracle Forms and Designer users, further simplifying web development. Based on the application structure definition, you generate a complete web application that automatically implements the best practices described in this guide, easily leveraging the most sophisticated features that Oracle ADF and JSF have to offer.
Whenever you run the JHeadstart application generator, rather than generating code, it creates (or regenerates) all of the declarative view and controller layer artifacts of your ADF-based web application. These use the ADF Model layer and work with your ADF application module as their business service. The generated files are the same kinds you produce when using JDeveloper's built-in visual editors. The key difference is that JHeadstart creates them in bulk based on a higher-level definition that you can iteratively refine until the generated pages match your end-users' requirements as closely as possible. The generated files include:
JSF Pages with data-bound ADF Faces UI components
ADF Model page definition XML files describing each page's data bindings
JSF navigation rules to handle page flow
Resource files containing localizable UI strings
Once you've generated a maximal amount of your application's web user interface, you can spend your time using JDeveloper's productive environment to tailor the results or to concentrate your effort on additional showcase pages that need special attention. Once you've modified a generated page, you can adjust a setting to avoid regenerating that page on subsequent runs of the application generator. Of course, since both the generated pages and your custom designed ones leverage the same ADF Faces UI components, all of your pages automatically inherit a consistent look and feel. For more information on how to get a fully-functional trial of JHeadstart for evaluation, including details on pricing, support, and additional services, see http://otn.oracle.com/consulting/9iServices/JHeadstart.html.
