Enterprise Java and ADF For Forms Developers: Taking it to the next level An Oracle White Paper July 2006 Enterprise Java and ADF For Forms Developers: Taking it to the next level Introduction ....................................................................................................... 3 Focussing on the business logic ...................................................................... 3 Introducing your framework....................................................................... 4 ADF Business Components ................................................................... 4 Code exposure, not generation .............................................................. 4 Extending the default behavior of ADF Business Components........... 6 Item level validation – When-Validate-Item........................................ 6 Record level validation – When-Validate-Record ............................... 8 Transactional triggers............................................................................... 8 When-Create-Record............................................................................... 9 When-Remove-Record.......................................................................... 10 Search Forms and Query By Example......................................................... 12 Search form.................................................................................................. 12 Execute with parameters ........................................................................... 13 Execute query.............................................................................................. 14 Focussing on the User Interface ................................................................... 15 Auto submit................................................................................................. 15 The stacked canvas..................................................................................... 17 The switcher component ...................................................................... 17 Conditional Page Flow............................................................................... 18 Application Look and Feel........................................................................ 20 Conclusion........................................................................................................ 21 Enterprise Java and ADF for Forms Developers: Taking it to the next level Page 2 Enterprise Java and ADF For Forms Developers: Taking it to the next level INTRODUCTION For many in the I.T world the opportunities opened up by the enterprise Java platform: SOA enablement (Service Oriented Architecture), standards based, wireless applications, rich Internet application, etc.; are see as exciting. However, the platform and development experience are perceived by some, to say the least, to be challenging. Oracle has been meeting this challenge head-on through the development of JDeveloper and the Oracle Application Development Framework (ADF). Many of the features in JDeveloper and ADF provide design-time and runtime productivity services not dissimilar to those found when developing using 4GL tools such as Oracle Forms; and as such, when it comes to building Java EE applications with JDeveloper and ADF, many of the development techniques and application requirements are met through familiar development gestures. This paper goes beyond the basic CRUD (Create, Remove, Update and Delete) set of operations already provided for you, and shows how you can supplement and extend the basic behavior by adding your own customized operations to perform enhanced record creation and deletes, validation, conditional page flow and UI processing; exactly as you did with Oracle Forms. FOCUSSING ON THE BUSINESS LOGIC At the heart of any application, and specifically those interacting with a database, is the business logic that implements the specific features of your business atop a more generic CRUD (Create, Retrieve, Update & Delete) set of features. As you do with Oracle Forms, you allow the runtime framework to perform the common CRUD actions, and those actions you complement with validation and business rules code. In some cases you also choose to tailor the default transactional features of the runtime to meet your application needs. ADF provides the same core features in the same way as the Forms runtime: a whole range of built-ins/APIs to manipulate your application objects, and Enterprise Java and ADF for Forms Developers: Taking it to the next level Page 3 numerous events/triggers where you can complement or override the runtime functionality. Introducing your framework The architecture of ADF is outside the scope of this paper so additional reading material can be found at http://www.oracle.com/technology/products/adf/index.html . However to briefly recap on the main elements referenced in this paper: ADF Business Components ADF Business Components provides a database focus to building business services in ADF. As a Forms developer you tend to build you Forms based on an existing database schema with SQL queries defining how data is manipulated from the database. ADF Business Components gives this same view of application development and does so using three main building blocks: Entity Object The entity object is, in nearly all cases, a one to one mapping to a database table. It implements the Object/Relational (O/R) mapping between a relational table and an object in the application. Each entity object typically has a number of attributes, each mapping to a column in the underlying database table. View Object The view object is a SQL query that selects a view of data from one or many database tables and can be thought of in a similar way to a Forms block or a database view, except within context of an application. Application Module The application module is a container of one or many view objects that define a user transaction: in the same way as a Forms module is usually related to a defined unit of work (e.g. maintain employees or check order status) This splitting of entity objects, view objects and application modules allows the reuse and modularization of business services. Code exposure, not generation Before embarking on a discussion on how to extend the functionality of ADF Business Components its worth re-emphasizing that JDeveloper and ADF do not work simply via mass code generation. The act of going through the ADF Business Components dialogs does not result in the automatic generation of thousands of lines of Java code. What happens is that XML meta data is generated and this meta data is read at runtime by ADF to implement the desired behavior. In theory, you can develop an ADF application without actually seeing a single line of Java code. Figure 1 shows an example of the meta data created for a Customers Enterprise Java and ADF for Forms Developers: Taking it to the next level Page 4 object. Information such as the attribute name, column name to which it maps, type and validation information (such as MaritalStatus must be single or married ) are held in this meta data format and read by the framework to implement the desired behavior. Figure 1 – XML Meta data to implement a Customers Entity Object There are many benefits associated with this approach, for example: • A change to metadata does not require re-compilation • Less code means less testing and fewer bugs • Runtime flexibility • Iterative exposure to code as developers become more familiar with the framework So, when you want to write Java code (as you wrote PL/SQL to extend your Oracle Forms) this is where JDeveloper and ADF give you a helping hand. By simply setting a check box (Figure 2), you can indicate to JDeveloper that you want to expose the Java methods that the framework will use to, for example, create a record. Enterprise Java and ADF for Forms Developers: Taking it to the next level Page 5 To be strictly correct, JDeveloper is not actually exposing the code the framework Figure 2 – Indicating what Java methods to expose on an Entity Object calls, it is providing you with a custom class that extends the basic functionality, and in that extended class you can override Once this code is exposed you can simply extend and augment the code to fit your the default functionality while still calling needs. the base class to “do the right thing” Extending the default behavior of ADF Business Components . So, now that you know you can expose the code behind the framework, lets look at some of the most common business actions for which you would want to extend the framework. Item level validation – When-Validate-Item The most common feature in any data entry application will be the validation of the data entered. Oracle Forms provides a when-validate-item trigger where the default validation of a Forms field can be supplemented with PL/SQL code. While ADF Business Components provides a much richer declarative validation framework even than Forms, it is expected that at some point you will want to validate a data field based on some complex scenario that requires code. Business case Consider that for your application you need to validate that the email address for a customer is valid. As an absolute minimum the email address should contain the “@” symbol. Implementation ADF Business Components provides declarative validation on an entity object and one facet of this validation is the ability to call a method validator for a specific attribute (Figure 3). Enterprise Java and ADF for Forms Developers: Taking it