Your organization has decided that the Oracle Application Development Framework (ADF) might be the right tool to build your next enterprise application—now you need to set up an experiment to prove that your assumption is correct.
You can compare the situation at the start of a project to standing in front of a mountain with the task to excavate a tunnel. The mountainsides are almost vertical, and there is no way for you to climb the mountain to figure out how wide it is. You can take either of the two approaches:
You can start blasting and drilling in the full width of the tunnel you need
You can start drilling a very small pilot tunnel all through the mountain and then expand it to full width later
It's probably more efficient to build in the full width of the tunnel straight from the beginning; however, this approach has some serious disadvantages, as well. You don't know how wide the mountain is, so you can't tell how long it will take to build the tunnel. In addition, you don't know what kind of surprises might lurk in the mountain—porous rocks, aquifers, or any number of other obstacles to your tunnel building.
That's why you should build the pilot tunnel first—so you know the size of the task and have an idea of the obstacles you might meet on the way.
The Proof of Concept is that pilot tunnel.
Since you have decided to evaluate ADF for your enterprise application, you probably already have a pretty good idea of its architecture and capabilities. Therefore, this section will only give you a very brief overview of ADF—there are many whitepapers, tutorials, and demonstrations available at the Oracle Technology Network (OTN) website. Your starting point for ADF information is http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html.
The frontend part is constructed from several layers. In a web-based application, these are normally arranged in the common model-view-controller (MVC) pattern, as illustrated in the following figure:
The view layer is interacting with the user, thus displaying data as well as receiving updates and user actions. The controller layer is in charge of interpreting user actions and deciding which screens are presented to the user in which order. The model layer is representing the backend business services to the view and controller layers, thus hiding the complexity of storing and retrieving data.
This architecture implements a clean separation of duties—the page doesn't have to worry about where to go next because that is the task of the controller. The controller doesn't have to worry about how to store data in the data service because that is the task of the model.
An enterprise application could also have a mobile application frontend or even use existing desktop applications, such as Microsoft Excel, to interact with data. In the ADF technology stack, all of these alternative frontends interact with the same model, making it easy to develop multiple frontend applications against the same data services.
The backend part consists of a business service layer that implements the business logic and provides some way of accessing the underlying data services. Business services can be implemented as API code written in Java, PL/SQL, or other languages, using web services or a business service framework such as ADF Business Components.
Under the business services layer, there will be a data service layer actually storing persistent data. Typically, this is based on relational tables, but it could also be XML files in a filesystem or data in other systems accessed through an interface.
There are many different ways of building applications with Oracle Application Development Framework, but Oracle has chosen a modern SOA-based architecture for Oracle Fusion Applications. This brand new product has been built from the ground up as the successor to Oracle E-Business Suite, Siebel, PeopleSoft, J.D. Edwards, and many other applications Oracle has acquired over the last couple of years.
If it's good enough for Oracle Fusion Applications, arguably the biggest enterprise application development effort ever undertaken by mankind, it's probably good enough for you, too.
ADF Controller (ADFc): This implements the features of a normal JSF controller, but is extended with the possibility to define modular, reusable page flows. ADFc also allows you to declare transaction boundaries, so one database transaction can span across many pages.
There are many ways of getting from A to B—this book is about traveling the straight and well-paved road Oracle has built for Fusion Applications. However, other routes might be appropriate in some situations; in the frontend part, you could use ADF Mobile for smartphones and tablets or ADF Desktop Integration to access your data directly from within Microsoft Excel, and in the backend, you could use business services based on Web Services, EJBs, or many other technologies and still use the ADF binding layer to connect the back and frontend parts together.
Entity objects (EOs) take care of object-relational mapping, making your relational tables available to the application as Java objects. Entity objects form the base that view objects are normally built on, and all data modifications go through the entity object. You will normally have one entity object for every database table or database view that your application uses, and this object is responsible for producing the correct SQL statements to insert, update, or delete data in the underlying relational tables.
The entity objects help you build scalable and well-performing applications by intelligently caching database records on the application server in order to minimize the load that the application places on the database.
Like entity objects are the middle-tier representation of database tables and database views, associations are the representation of foreign key relationships between tables. An association implements a connection between two entity objects and allows ADF to connect data in one entity object with data in another. JDeveloper is normally able to create associations automatically by simply inspecting the database, but in case your database does not contain foreign keys, you can build associations manually to let ADF know about the relationships in your data.
While you don't really need to make any major decisions when building the entity objects for the Proof of Concept, you do need to consider the consumers of your business services when you start building view objects—for example, what information you would display on a screen.
To provide data for your screens
To provide data for lists of values (LOVs)
The data handling view objects are normally specific to each screen or business service. One screen can use multiple view objects. If you have master-detail data, for example, departments containing employees, you create one view object for each master-detail level you wish to display on your screen (for example, one department and one employee view object).
One view object can pull together data from several entity objects. If you need to look up a reference value from another table, you don't need to create a separate view object for this. For example, an employee entity object might contain only the department number. If you want your view object to display the department name, you need to include the department entity object in the view object in order to retrieve it.
The LOV view objects are used for drop-down lists and other selections in your user interface. They are typically defined as read-only, and because they can be reused, you can define them once and re-use them everywhere you need a drop-down list on a specific data set.
The following figure shows an example of two ways to display data from the familiar
DEPT tables found in the
The left-hand side illustration shows a situation in which you wish to display a department with all of its employees in a master-detail screen. In this case, you create two view objects connected by a view link. The right-hand side illustration shows a situation in which you wish to display all employees together with the name of the department they work in. In this case, you only need one view object pulling together data from both the
DEPT tables through the entity objects.
Application modules encapsulate the view object instances and business service methods necessary to perform a unit of work. Each application module has its own transactional context and holds its own database connection. This means that all of the work a user performs using view objects from one application module is part of one database transaction.
Application modules can have different granularity, but typically, you will have one application module for each major subsystem in your application. However, there is no limit to the amount of functionality you can put into one application module—indeed, it is possible to build a small application using just one application module.
Application modules for Oracle Forms
If you come from an Oracle Forms background and are developing a replacement for an Oracle Forms application, your application will often have a relatively small number of complex, major forms and a larger number of simple data maintenance forms. You will often create one application module per major form and a few application modules, each of which provides data, for a number of simple forms.
If you wish, you can combine multiple application modules inside one root application module. This is called nesting and allows several application modules to participate in the transaction of the root application module. This also saves database connections because only the root application module needs a connection.
The preferred way of building the user interface in an ADF enterprise application is with JavaServer Faces (JSF). JSF is a component-based framework for building web-based user interfaces that overcome many of the limitations of earlier technologies such as JavaServer Pages (JSP).
In a JSF application, the user interface does not contain any code but is built from the configurable components of a component library instead. For your application, you'll want to use the sophisticated ADF 12c JSF component library known as the ADF Faces Rich Client.
It had long been clear to web developers that in a web application, you cannot just let each page decide where to go next—you need the controller from the MVC architecture. Various frameworks and technologies have implemented controllers (both the popular Struts framework and JSF have this), but the controller in ADF Task Flows was the first one capable of handling large enterprise applications.
An ADF web application has one unbounded task flow where you place all of the publicly accessible pages and define the navigation between them. This corresponds to other controller architectures such as Apache Struts. The user can enter an unbounded task flow on any page. However, ADF also has bounded task flows, which are complete, reusable mini applications that can be called from an unbounded task flow or from another bounded task flow.
A bounded task flow has a well-defined entry point, accepts input parameters, and can return an outcome back to the caller. For example, you might build a customer management task flow to handle customer data. In this way, your application can be built in a modular fashion—the developers in charge of implementing each use case can define their own bounded task flow with a well-defined interface for others to call. The team building the customer management task flow is thus free to add new pages or change the navigation flow without affecting the rest of the application.
The concepts behind ADF Task Flows have influenced the JSF 2.2 standard, where this approach is known as Faces Flows. However, ADF Task Flows have more features and a different technical implementation.
In bounded task flows, you can define either pages or page fragments. Pages are complete web pages that can be run on their own, while page fragments are reusable components that you can place inside regions on pages.
You can choose to build your ADF application as either a traditional web application or a Rich Internet Application (RIA). A traditional web application consists of pages—when the user interacts with the application, the whole browser window will redraw, thus showing the next page of the application. In a Rich Internet Application, on the other hand, you will have a small number of pages (possibly only one) and a larger number of page fragments. These page fragments will dynamically replace each other inside a region on an application page, so the user sees only a part of the page change. If you choose this technique, your application will seem more like a desktop application than a traditional web application.
On your pages or page fragments, you can add content using layout components, data components, and control components:
Data components: These are the components that the user interacts with to create and modify data. Data components range from fairly simple components, such as an input field or a checkbox, to very sophisticated components, such as an ADF table.
The Proof of Concept serves two purposes:
If we return to the tunnel analogy, we need to demonstrate that we can drill all the way through the mountain and measure our drilling speed.
The most important part of the Proof of Concept is that it goes all the way through the mountain, or in application development terms, all the way from the user interface to the backend data service and back.
If your data service is data in relational tables and you will be using the ADF technology stack (ADF Business Components and ADF Faces), the part of your Proof of Concept that demonstrates the technology is fairly straightforward.
However, if for some reason, you decide to not use ADF Business Components or you want to base your business components on something other than relational tables, things get more complicated. It might be that your data service is based on Web Services or API code in C++, Java, or PL/SQL. In this case, you will need to demonstrate that you can retrieve data from your data service, display it on the screen, modify it, and successfully store the changes in the backend data service.
You might also have user interface requirements that require more advanced components such as trees, graphs, or even drag-and-drop functionality for the end user. If that's the case, your Proof of Concept user interface needs to demonstrate the use of these special components.
There might also be other significant requirements you need to consider. Your application might have to use a legacy authentication mechanism such as a database login. Another possibility is it might have to integrate with legacy systems for authorization or customization, or you might need to support accessibility standards allowing your application to be used by people with disabilities. If you have these kinds of requirements, you have to evaluate the impact on your project if you can't meet them. If they are critical to your project's success; you need to validate them in a Proof of Concept.
The ADF technology obviously works. Hundreds of organizations have already followed Oracle's lead and built big enterprise applications using Oracle ADF. It is very straightforward to use the ADF framework with relational tables; the framework handles all of the boring object-relational mapping, allowing you to concentrate on building the actual application logic.
You are likely to inherit at least some of the data models from a pre-existing system, but in rare cases, you will be building a data model from scratch for a brand new application. JDeveloper does allow you to build data models, but Oracle also has other tools (for example, SQL Developer Data Modeler) that are specialized for the task of data modeling. Either way, the ADF framework does not place any specific restrictions on your data model—any good data model will work great with ADF.
But your requirements are special, of course. Nobody has ever built an application like the one you are about to build—that's the essence of a project: to do something non-trivial that has not been done before. After all, if you didn't need anything special, you could just pick up a standard product off the shelf. So, you need to consider all of your specific requirements to see if ADF can do it.
ADF can still do it. The ADF framework is immensely powerful as it is, but it also allows you to modify the functionality of ADF applications in myriad ways to meet any conceivable requirement. For instance, if you have to work through a data access API, you can override the
doDML() method in entity objects, allowing you to say, "Instead of issuing an
UPDATE SQL statement, call this API instead." If you need to work with existing web services for modifying data, you can create data sources from web services.
However, you shouldn't just take my word (or anybody else's word) for it. Building an enterprise application is a major undertaking for your organization, and you want to prove that your application can meet the requirements.
The development speed of a task mainly depends on three factors: the size of the task, the complexity of the task, and the speed of development.
The size and complexity of the task is given by your requirements. It would be a rare project where all of the requirements are exactly known at the beginning of the project, but if you have a set of detailed requirements, you can make a good estimate of the project's size and complexity.
The speed of development will be the greatest unknown factor if ADF is new to you and your team. Using your previous development tool (for example, Oracle Forms), you were probably able to convert your knowledge of project size and complexity into development effort, but you don't yet know what your development speed with ADF will be.
Your relationship with your development tool will go through a number of phases—not unlike a romantic relationship. Using the terminology of some of the countless relationship coaches on the Internet, we can identify three phases of a relationship:
During the infatuation stage, your development speed is fairly high. You will be building the types of functionalities illustrated in the tool tutorials—fairly simple stuff that the tool supports really well.
After this stage comes power struggle. You want to implement some specific functionality and the tool simply refuses to cooperate. During this stage, your development speed drops (and your frustration rises…).
Assuming that the relationship between you and your tool survives this phase, you can move on to the co-creativity stage. This is where you understand the tool: you know its strengths and how to overcome its weaknesses. During this stage, your productivity recovers to the initial level and continues to grow to a higher and higher level.
Graphically, it will look as shown in the following figure:
If you have to provide an estimate of development speed very early in the project, you can use your initial development speed as an approximation of the productive development speed you will eventually reach. However, if you do this, you must be aware of the period of lower productivity before you start climbing up with your full productive development speed.
Many developers working on their own find that after a few weeks of infatuation, the power struggle phase can take up to 3-6 months before productivity starts to climb again. If you want to move forward faster, you need to break out of your isolation and get some help.
In my experience, typical classroom training is not enough to move through the struggle phase. Try to find an experienced ADF developer who can both teach and offer mentoring and support you on your way to mastering ADF. Also, use the Oracle Technology Network forums (available at otn.oracle.com/forums), where you'll find a community of experts willing to help.
The outcome of the Proof of Concept is not an architecture in the form of boxes and arrows on a PowerPoint slide. David Clark from the Internet Engineering Task Force said, We believe in running code—and that's what the Proof of Concept should deliver in order to be credible to developers, users, and management: running code.
Additionally, it is a good idea to record the running Proof of Concept application with a screen-recording tool and distribute the resulting video file. This kind of demo tends to be watched at many places in the organization and gives your project visibility and momentum.
You are a developer with DMC Solutions, an IT company selling a system for Destination Management Companies (DMC). A DMC is a specialized travel agency, sometimes called an "incoming" agency, and works with clients in the country where it is based.
On an average packaged tour, you will probably not enjoy the services of a DMC. But if you manage to qualify for a company-paid trip to some exotic location, your company is likely to engage the services of a DMC at the destination. If you have ever participated in a technology conference, a DMC will normally be taking care of transfers, dinners, receptions, and so on.
The system that DMC Solutions is selling today is based on Oracle Forms, and the sales force is saying that our competitors are offering systems with a more modern look and a more user-friendly interface. Your mission, should you choose to accept it, would be to prove that ADF is a valid choice for a modern enterprise application, and if so, set up a project to build the next generation of destination management software (the XDM project).
The rest of this chapter shows you how to build the Proof of Concept application implementing two use cases. You can simply read through it to get a feel of the tasks involved in creating an ADF application, or you can use it as an ADF hands-on exercise and perform each step in JDeveloper on your own.
Your manager has dusted off the specification binder for the existing system and has asked you to implement "Use Case 008 Task Overview and Edit". Additionally, he wants you to implement the newly specified "Use Case 104 Person Task Timeline".
These two use cases represent the application's basic functionality (the ability to search and edit data), as well as a graphical representation of time data, something new that wasn't possible in Oracle Forms.
The UC008 Task Overview and Edit screen allows the user to search for tasks by the responsible person, program, or a free-text search, as shown in the following screenshot. Data can be updated and saved back to the database.
DMC Solutions is a British company, so they use the British English term "programme". This term is used because British English makes a distinction between "programme" (a set of structured activities) and a "program" (something that runs on a computer). The screen is not a dialog box, but uses OK to accept changes and save data, and Cancel to cancel any changes and revert to the saved data. For simplicity, we will not implement the application menu, but just have a button labeled Timeline that invokes UC104 instead.
Again, we will not have a menu, just a button called Overview for returning to UC008.
The destination management system starts with events, such as "Oracle OpenWorld 2014". Within each event, there will be a number of programmes (for example, "VIP Pharma Customers"). One person is responsible for each programme. Within a programme, there will be a number of tasks that point to standard elements from the element catalog. Examples of elements could be a limo transfer, a dinner, an excursion, and so on. Each task will be assigned to exactly one person.
If you want to follow along with the Proof of Concept, building it in JDeveloper on your own workstation, you can download SQL scripts for creating the relevant part of the data model from the book companion website at www.enterpriseadf.com. This script also contains some anonymous data.
Oracle JDeveloper is Oracle's strategic development tool and the only tool with full support for all aspects of ADF development. While Oracle offers a lot of functionalities for Eclipse (with Oracle Enterprise Pack for Eclipse), they have also clearly stated that JDeveloper is the preferred tool for building Oracle ADF applications.
JDeveloper is freely available for download and use from the Oracle Technology Network (otn.oracle.com)—look under Downloads and then Developer Tools. If you don't already have a free Oracle account, you will have to create one.
The illustrations in this book use JDeveloper 12c, Version 22.214.171.124.0. If a later version of JDeveloper is out by the time you read this book, use that instead. The basics of ADF development have not changed over the last couple of years, so you should be able to immediately find the dialogs and options you are looking for. In addition, since Oracle has built a very large application based on JDeveloper, you can be sure that there will be a simple migration path moving forward.
Navigate to File | New | Application. Choose ADF Fusion Web Application. JDeveloper offers you many other types of applications, including ADF Java Desktop Application, but you want an ADF Fusion Web Application. Click on OK.
Give your application the name,
XdmPoC, choose where to put it in the filesystem (you can leave the default—just note where your projects are stored), and provide an Application Package Prefix. Use your organization Java prefix followed by your project abbreviation (for the Proof of Concept, use
Java package prefix
Traditionally, package names start with your organization's Internet domain with the elements reversed. So, if your company domain is
mycompany.com, your package names would all start with
com.mycompany. However, some organizations (such as Oracle) feel that their names are sufficiently unique, and they don't need to include the first
If your organization has ever used Java earlier, your Java package prefix has probably already been chosen and documented somewhere. Ask around.
You can simply click on Next through the rest of the wizard.
The application checklist actually gives a great overview of the steps involved in building an ADF application, and if you click on the little triangles to expand each step, you'll see links to the relevant JDeveloper functionality for that step, together with links to the relevant places in the documentation. It even has checkboxes that you can check as you complete the different phases in developing your ADF application.
JDeveloper contains a lot of different windows and panels for different purposes. The preceding screenshot shows the most commonly used panels, but you can toggle each of the many panels on and off using the Window menu.
In the top-left corner is the Applications window where you can see all of the components in your workspace in a hierarchical structure.
In the bottom-left corner is the Structure window. This important window shows the detailed structure of the component you are working on. For example, when you are working on a page in the main window, the Structure window will show a tree with all of the components on the page.
In the top-right corner is the Resources window showing connections to the application servers, databases, and so on. The Components window will also appear as a separate tab in this location when editing a page, allowing you to select components to add to the page.
You can rearrange these panels to your liking by grabbing the tab at the top of each panel and dragging it to a new location, or even dragging it out of JDeveloper to make it a floating window. This can be useful if you have multiple monitors. If you accidentally change the layout to something you don't like, you can always navigate to Window | Reset Windows To Factory Settings.
Before you start working with JDeveloper, you should set the preferences (under Tools | Preferences). There are literally hundreds of preferences to set, most of which will not mean anything to you yet. The defaults are mostly fine, but feel free to change the settings. The Help section explains the various options well.
One setting that you should change is the business package naming. Open the ADF Business Components node and choose Packages. Set values for Entity, Association, View Object, View Link, and Application Module, as shown in the following screenshot:
These settings tell JDeveloper to place different types of business components in separate Java subpackages for an easier overview when you have many components. These are just defaults to create a good starting point. As you build your application, you might decide to move your business components and classes to other packages, and JDeveloper makes this safe and easy.
You should also set Encoding on the Environment node to
UTF-8 to have all of your files created in
UTF-8 for maximum cross-platform portability. (If you're using Microsoft Windows, this value is probably set to a default Windows character encoding.)
Once the data model is in place, the next step is to build the ADF Business Components. The description in this book is fairly brief and assumes that you have worked a little bit with ADF earlier, for example, by going through a basic ADF tutorial on the Oracle Technology Network website (otn.oracle.com). You can find links to some relevant tutorials on the book companion website (www.enterpriseadf.com).
For the Proof of Concept, we will leave all business components in the default location: the Model project in the Proof of Concept application workspace. However, when building a real-life enterprise ADF application, you will be splitting up your application into multiple application workspaces and using ADF Libraries to compile these into the master application. Working with smaller workspaces enforces modularity in the code, makes it faster for the developer to find what he's looking for, allows faster checkouts from source control, and JDeveloper also runs faster and better when it is not handling thousands of objects at the same time.
We'll return to the proper structuring of workspaces in Chapter 3, Getting Organized.
As you might have noticed from the application checklist, the first step after Plan your Application is to create a connection to the database schema where your application tables reside. Press Ctrl + N (or command + N on Mac) to bring up the New Gallery dialog, choose Connections (under General), and then choose Database Connection.
Each application workspace has its own connections, but you can also create general connections in JDeveloper that you can later copy into your applications. To create general connections, set the value of Create Connection in to IDE Connections.
In the Create Database Connection dialog, give your connection a name (
xdmpoc) and provide a username, password, and connection information. If you are working locally with the small, free version of the Oracle Database (Oracle Express Edition 11g), you choose the "thin" driver,
localhost as Host Name, leave JDBC Port at the default value of
1521, and enter
xe in the SID field. A default local installation of other database editions (version 11g and earlier) would use the same values for Host Name and JDBC Port, but the value of SID would be
If you are running against a local Oracle 12c database and have decided to implement the
multitenant architecture, your data should live in a pluggable database (PDB), not in the
container database (CDB). If you perform a default Oracle 12c database installation and call
orcl, you get a pluggable database called
pdborcl. To connect to this PDB,
set the Service Name to
pdborcl.lan. Just using SID
orcl will connect to the CDB.
If you are running against a remote database, ask your database administrator for connection information. Click on Test Connection to check that you have entered everything correctly and then click on OK, as shown in the following screenshot:
For the Proof of Concept, we will only be building entity objects for the tables for which we need to meet the requirements of the two use cases. To start building, right-click on the Model project, choose New from the context menu, and then click on Entity Object.
Make sure that you select the Model project before you start creating business components. A default ADF Fusion Web Application workspace comes with two projects: a Model project for the business components and a ViewController project for the user interface.
The Initialize Business Components Project dialog appears the first time you create a business object. In this dialog, leave the database selection to Online Database, select your database connection, and set SQL Platform to Oracle and Data Type Map to Java Extended for Oracle. Then click on OK.
This book assumes that you use an Oracle database, and the above selections are recommended for this. If you are not using an Oracle database, you can choose SQL92 as SQL Platform and Java as Data Type Map. Click on the Help button in the dialog for more information on these choices.
When you start your enterprise application development project in earnest, you need naming standards for everyone to follow. We'll return to naming standards in Chapter 3, Getting Organized.
In step 2 of the wizard, just click on Next to create entity object attributes for every column in the database. In ADF, there is no overhead at run time for having attributes for unused columns—when the ADF framework issues a
SELECT statement to the database, it retrieves only those attributes that are actually needed by the view object.
In step 3 of the wizard, you can define the entity attributes in detail. One thing that often needs to be changed here is the type for primary key columns. If the table has a numeric ID column and a database trigger that sets this value when the record is created in the database, you need to set the Type to DBSequence. Do this for the
PersId attribute, as shown in the following screenshot:
Notice that the ADF framework has now changed the values in the right-hand side of the dialog box: Updatable is now set to While New, and in the Refresh After box, the checkbox for Insert is now checked. This means that the entity object will automatically retrieve the primary key value created by your trigger. If you are using an Oracle database, ADF will use the
RETURNING feature in Oracle SQL to get the ID back as part of the
INSERT command (without having to make a second round-trip to the database).
You don't have to make any changes in steps 4 through 6, so you can simply click on Finish here to close the wizard and create your entity object.
For the Proof of Concept, repeat the procedure discussed earlier and create the following entity objects:
XDM_PROGRAMMES(choose DBSequence for the attribute
XDM_TASKS(choose DBSequence for the
XDM_ELEMENTS(doesn't need DBSequence for any attribute)
When you are done, the Model project in the application navigator should look as shown in the following screenshot:
If you have configured JDeveloper Preferences as recommended in the introduction, all of the associations can be found in the application navigator under
assoc, as shown in the preceding screenshot.
To determine which view objects to build, you must look at the screens you need. This allows you to determine both the data you need to present and the value lists you'll need.
Additionally, we'll need three value lists:
Programmes (for the Programme drop-down list for search)
Persons (for the Responsible drop-down list for search)
Services (for the Service drop-down list in the data table)
Looking at the Person Task Timeline screen (UC104), there are clearly no value lists. As data is presented graphically, it's not immediately obvious whether the data contains any master-detail relationship. To determine if that is the case, consider how you would display the same information in ordinary fields and tables. Such a screen might show:
A number of tasks assigned to that person
This shows us that there is actually a master-detail relationship hidden here, so we need one view object for Persons, one view object for their Tasks, and a view link connecting the two.
To create view objects for persons, right-click on the Model project and navigate to New | View Object. It's a good idea to give your view object a name that indicates its intended usage as a list of values. For the list of persons, use the name
PersonLOV. Leave the data source at Entity Object.
Always use entity objects
In ADF 10g and earlier versions, the recommendation was to use SQL Query when you did not need to change the data. Since ADF 11g, the benefit of caching those entity objects outweighs the slight performance benefit from executing SQL directly. The recommendation is, therefore, to access data through entity objects always.
In step 2 of the wizard, choose the
Person entity object and move it to the box to the right. You can remove the checkmark in the Updatable box since we will only be using this view object for the drop-down list, as shown in the following screenshot:
In step 3 of the wizard, move the fields you want to the right-hand side—in this case, we just need
Initials. Note that the primary key attribute will always be included, as shown in the following screenshot:
In step 5 (
Query), you define the ordering of records by entering
Initials in the Order By field. Then, click on Finish to create the view object.
ProgrammeLOV(based on the
Programmeentity object, not updatable; select the attribute called
Name, order by
ServiceLOV(based on the
Elemententity object, not updatable; select the attribute called
Description, order by
To create a view object for tasks, look at the Task Overview, Edit page (UC008), and data model. You'll notice that we need fields for date and time, text, start where, flight number, end where, number of passengers, and service. All of this data comes from the
XDM_TASKS table through the
Task entity object.
Create a new view object (
AllTasksVO), leaving the data source at Entity Object. In step 2 of the wizard, choose the
Task entity object and move it to the right-hand side. As we will actually be updating data through the
AllTasksVO view object, we leave the check mark in the Updatable checkbox.
In step 3, shuttle the following fields to the right-hand side:
Note that in the Available box on the left-hand side, all attributes are shown in alphabetical order, not in the order you placed them in the entity objects or the order they have in the database table.
Click on Next twice and choose to order by
start_date. Then click on Next to get to Bind Variables (step 6).
Bind variables are placeholders in your SQL that you fill with values at run time. The ADF framework enforces the good practice of always using bind variables when you need to change the
WHERE condition of a query. You should never simply concatenate values into an SQL statement; if you do, the database can't tell that it already knows the SQL statement and will waste time parsing it again, and a malicious user could potentially insert extra statements into your SQL.
Looking at the search box at the top of the screen sketch, you can see that we need to limit the tasks displayed by responsible person, programme, and text. Use the New button to create three bind variables called
pText (all of them of type
String). You can leave the other settings in this step of the wizard at their default values.
When you're done, click on the Back button to return to step 5 of the wizard and add a
WHERE clause that uses the bind variables. It should look similar to the following code:
(:pResponsible is null or PERS_ID = :pResponsible) and (:pProgramme is null or PROG_ID = :pProgramme) and (:pText is null or upper(TEXT) like '%' || upper(:pText) || '%')
In this case, we allow null values for the bind variables, so the SQL statement has to contain an
OR branch handling this case. We are converting both the database
TEXT column and the
pText bind variable to upper case to achieve case-insensitive matching. We are also concatenating a wildcard character before and after the parameter value to search for occurrences of the search text anywhere in the database value.
Point-and-click Where clauses
You can also define Named View Criteria on your view objects (on the Query subtab). These allow you to build a
WHERE clause by pointing and clicking. Read about named view criteria and the associated
af:query component in the online Help section.
When you click on Finish, the
AllTasksVO view object is created and appears in the application navigator.
However, we are not quite done with the view object—we still need to define which data elements use lists of values. You might remember from the page layout illustration that Service was rendered as a drop-down listbox. Double-click on the
AllTasksVO view object to edit it and choose the Attributes subtab on the left-hand side. Choose the
ElemKey attribute and then select the List of Values tab at the bottom of the view object window. Click on the green plus sign to bring up the Create List of Values dialog, as shown in the following screenshot:
In this dialog, click on the green plus sign to add the List Data Source. Choose the
ServiceLOV view object and then
ElemKey as List Attribute.
Since we don't want to display the actual key value (
ElemKey) to the user, choose the UI Hints tab and move the
Description attribute to the right-hand side box. Uncheck the Include "No Selection" Item checkbox and then click on OK.
The Attributes tab also allows you to define some hints to the user interface components about rendering the component. Click on the
StartDate attribute and choose the UI Hints tab at the bottom of the view object window. Set the label to
Start time, set Format Type to Simple Date, and in the Format field, enter the format mask,
The date format string used here is Java
SimpleDateFormat, not the SQL data format strings you might be familiar with from the database.
Taking a hint
The control hints defined here are just hints. When building the user interface, these will be the default, but you can still decide to use another label text or format when you use the view object on a page. For simplicity, we are hardwiring labels into the application—in a real-life application, texts should go into separate resource bundles. Refer to Appendix, Internationalization, for more information.
To create an application module for tasks, right-click on the Model project and navigate to New | Application Module. Name the application module as
EditTaskService. In step 2 of the wizard, expand the tree in the left-hand side and shuttle the
AllTasksVO view object to the right, together with the
ProgrammeLOV that we need to create the search criteria value lists. This is all you need to do, so you can simply click on Finish to close the wizard.
Note that the view object instances on the right-hand side get the name of the view object with a number appended to them by default. For example, the
AllTasksVO view object becomes the view object instance,
AllTasksVO1. The instance name is part of the contract between the business service and the user interface—if you want to change it, do so before anybody starts building the user interface. The reason for this default is that it is possible to have several view object instances based on the same view object in an application module.
Now, you can verify that your application module works the way you expected it to. In the Applications window, right-click on the EditTaskService application module node (the icon that looks like a little suitcase) and choose Run from the context menu. This will start the Oracle ADF Model Tester where you can work with all of the view objects that are part of your application module.
Always test your business components using the Oracle ADF Model Tester before you start using them in pages. Whenever your page doesn't run the way you expected, always use the ADF Model Tester to determine if the error is in the frontend or the backend part of the application.
Double-click on the
AllTasksVO1 view object instance. A pop-up dialog appears, allowing you to assign values to all the bind variables defined in the view objects. To begin, just click on OK to leave all bind variables at the
NULL value. You should see the data in the
AllTasksVO view object, as shown in the following screenshot:
Here, you can page through the existing data, as well as insert and delete rows, using the green plus and red cross symbols. Click on the Edit Bind Variables button (to the right of the toolbar, with the little pencil icon) to change bind variable values and notice how the data is filtered.
For the scheduling screen, we need two view objects: one for persons and one for the tasks assigned to persons.
We already have a view object showing persons, but this view object only contains the initials (because it was intended for the
Persons drop-down list in UC008). We could create a new
Persons view object for UC104; however, we'll change the existing view object instead.
First, you need to change the name of the view object from
PersonsVO to reflect that it's no longer just used for a list of values. Changing the name or package for existing objects is called refactoring, and JDeveloper makes this easy. Simply right-click on the
PersonLOV view object and choose Refactor | Rename from the context menu. JDeveloper will change the name of the object and automatically update all of the references to it, as shown in the following screenshot:
Next, the view object needs some more attributes. To add these, open the view object by double-clicking on it and choose the Attributes subtab. Click on the little triangle next to the green plus sign above the attributes and choose Add Attribute from Entity, as shown in the following screenshot. Don't just click on the plus sign—you need to select the little triangle to get access to the Add Attribute from Entity menu item.
In the Attributes dialog, add the
LastName attributes to the Selected list and click on OK. Then, select the new
FirstName attribute, select the UI Hints tab at the bottom of the view object window, and set a Label. Repeat this procedure for the
Next, create another view object, giving it the name
ScheduledTasksVO. In step 2 of the wizard, move the
Task entity object to the right-hand side. As we won't be updating tasks either, you can remove the checkbox in the Updatable field here. In step 3 of the wizard, you only need to select the
EndDate attributes—note that the
TaskId primary key attribute is automatically added.
In step 5 of the wizard, we need to add a
WHERE clause so that the view object will only show tasks with both, a start and an end date. Enter the following
start_date is not null and end_date is not null
Then, click on Finish.
Since there is a master-detail relationship between persons and tasks, we also need to create a view link. Right-click on the Model project and choose New | View Link. Name your view link
In step 2 of the wizard, we need to define the relationship between the two view objects. These are connected by the foreign key,
XDM_PERS_TASK_FK, that defines the connection between a person and the tasks assigned to that person. Leave the Cardinality selection at 0..1 to * (this means that one person may have one or more tasks), expand the
PersonsVO node on the left-hand side, and choose
XdmPersTaskFkAssoc at the left-hand side of the link. On the right-hand side, expand the
ScheduledTasksVO node and choose
PersTaskFkAssoc again, this time at the right-hand side of the link. Then, click on Add. You can see the source and destination attributes added at the bottom of the dialog box, as shown in the following screenshot:
One lump or two?
You want to modularize your application so that each piece of functionality is completely developed and delivered by one team. This means that each subsystem gets its own application module. When you put together the final application, you can choose whether you want each subsystem (and each application module) to have its own transaction and database connection or whether they should share the transaction context. We'll return to the discussion of the proper number of application modules in Chapter 3, Getting Organized.
In step 2 of the wizard, first move the
PersonsVO view object to the right-hand side. Then, select the
PersonsVO1 view object instance on the right-hand side and the node
ScheduledTasksVO via PersonTasksLink on the left-hand side, and click on the > button to move
ScheduledTasksVO to the right-hand side box, as shown in the following screenshot:
Note the difference between choosing
ScheduledTasksVO on its own and choosing
ScheduledTasksVO as a child of
PersonsVO. If you choose the view object as a child of another view object, the ADF framework will automatically implement the master-detail relationship; the view object will only display the records that are children of the current record in the parent (master) view object. If you choose the view object on its own, it will not have any relationship to the master view object and will simply display all child records.
Then, click on Finish to close the wizard.
Run your new application module in the ADF Model Tester. In the left-hand side, you'll see the master view object, the view link, and the detail view object. Double-click on the view link to see the master and detail records together. When you use the navigation buttons at the master level, you will see different detail records displayed, as shown in the following screenshot:
Pages or fragments?
As mentioned in the The ADF architecture section, an application can use either pages or page fragments. The Proof of Concept uses pages for simplicity, while the professional Proof of Concept we'll be building in Chapter 6, Building the Enterprise Application, will use page fragments.
For the Proof of Concept, we will implement one bounded ADF task flow. Right-click on the ViewController project and choose New. You might notice that the context menu looks different now. That's because the ViewController project uses technologies that are different from the Model project.
Choose ADF Task Flow and name it
xdm-poc-flow. Make sure that the Create as Bounded Task Flow checkbox is checked and the Create with Page Fragments checkbox is not checked. Then click on OK. You will see a blank task flow diagram in the JDeveloper main window.
The Proof of Concept is page-based, like a traditional web application. Later in this book, we will see another example where we use page fragments to build a modern Rich Internet Application.
In the component palette in the top-right corner of the JDeveloper window, expand the Components heading and drag in a View component. Give it the name
TaskPage. Drag in another View component and name it
Then, drag in a Control Flow Case component (the green arrow) and drop it on the
TaskPage. Move the cursor to the
SchedulePage and click on it. This establishes a control flow from the
TaskPage to the
SchedulePage. The cursor will be placed in a box in the middle of the line. Type
goSchedule in this box and press return. Drop another Control Flow Case onto the
SchedulePage and drag it to the
TaskPage. Name this control flow
This defines the two pages that we will be using in the Proof of Concept, as well as the possible navigation between them. Your task flow should look like the following screenshot:
Note the green halo behind the
TaskPage. It indicates that this page is the default activity—the first thing to happen when the task flow is invoked. You can make another activity (View, Method Call, and so on) the default by right-clicking on it and choosing Mark Activity and then Default Activity.
You might notice that the icon in both of the pages in the task flow diagram have a dotted and pixelated lower half. This indicates that the pages don't actually exist yet—they are only defined as placeholders in the task flow.
To create the tasks page, double-click on the
TaskPage icon in the page flow diagram. The Create JSF Page dialog appears. For the Proof of Concept, we start with blank pages (make sure that Create Blank Page is selected)—but when actually building the real application, we will, of course, be using the page templates. Set Document Type to Facelets and click on OK to create and open the page.
Facelets is the modern way of rendering a JSF page and is superior to JSP XML. Always choose Facelets for new pages. For more information, refer to the Oracle whitepaper, JavaServer Faces 2.0 Overview and Adoption Roadmap in Oracle ADF Faces and Oracle JDeveloper 11g, available at http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adffaces-jsf20-190927.pdf.
There are two ways of placing ADF components on a JSF page: you can drag them in from the Components palette on the right-hand side, or you can drag them in from the Data Controls palette in the Applications window on the left-hand side, as follows:
If you drag in a component from the Components palette, it is not bound to any data control. This means it has no connection to the data in the ADF Business Components. You can create bindings manually, but it is more work.
If you drag in the data control from the Data Controls palette, JDeveloper will automatically present you with a menu of components that you can drop onto the page. If you use this approach, the dropped component is automatically bound to the data control you dragged in.
To add components to the task page, find and open the Data Controls panel in the Applications window on the left-hand side of the JDeveloper window. You should see two data controls corresponding to the two application modules you have created in the Model project:
ScheduledTaskServiceDataControl, as shown in the following screenshot:
However, before we start dragging in data controls, we need to place a layout component on the page to control where the items are to be placed. If you come from a 4GL background (such as Oracle Forms), you might be used to pixel-precise placement of items. In JSF, on the other hand, the placement of components is controlled by special layout components. This has the advantage that the layout components can arrange, shrink, and expand the components they contain in order to make the best use of the available screen area. The disadvantage of this approach is that it takes a little while to learn to use the right layout components.
TaskPage, we start with a Panel Stretch Layout. Find this component in the Component Palette on the right-hand side of the JDeveloper window (under the Layout heading) and drop it on the page, as shown in the following screenshot:
It is a good idea to use a "stretchable" layout component as the outer layer to ensure that your application will utilize the entire browser window.
The structure of your page is represented visually in the work area, but you can also see a hierarchical representation of the components on the page on the Structure window (by default, they are placed in the bottom-left corner of the JDeveloper screen). If you expand the Panel Stretch Layout on the Structure window, you will see that it shows a folder-like node called Panel Stretch Layout Facets and additional folder-like nodes called bottom, center, and so on under that, as shown in the following screenshot. Many layout containers contain these containers (called facets) that you can place your content in.
If you refer to the screen design earlier in this chapter, you will see that the Panel Stretch Layout matches our requirements: we can place the search criteria on top (in the facet called top), the actual data in the middle (in the facet called center), and some buttons at the bottom (in the facet called bottom). We don't need the start and end facets, so we don't have to worry about them. Facets without content are not shown at run time.
We will start with the actual data, which we will present using an ADF Table component. Open the Data Controls panel on the right-hand side, and then open the
EditTaskServiceDataControl node. You will see the
AllTasksVO1 view object instance. Grab the entire view object instance (the red and orange icon) and drag it onto the center facet, as shown in the following screenshot:
When you drop a data control onto a page, JDeveloper shows a context menu asking you which user interface elements you want to create and bind to the data control. In this case, select Table/List View first and then ADF Table from the context menu. The Create Table dialog appears, as shown in the following screenshot:
In this dialog box, you can remove the columns that you don't need and re-order the columns if necessary. You will see that JDeveloper has automatically selected an appropriate UI component—ADF Input Date for date attributes and ADF Select One Choice for attributes where a value list has been defined. For the tasks table, you only need to delete the
TaskId column. You can also enable data sorting by clicking on the column headers by selecting the Enable Sorting checkbox. Then, click on OK. You will see a table component in the middle of your page.
Finally, you need to notify ADF which column gets to use any extra space on the screen. Remember that we started with a Panel Stretch Layout, which will automatically stretch the components it contains, but a table component doesn't stretch until you specify which column should expand to use any extra space.
First, select the Text column and make a note of its Id property (look in the Properties window in the lower-right corner of the JDeveloper window)—it will be something similar to
c2. Then, select the entire table (either in the Design window in the middle of the JDeveloper window or in the Structure window on the bottom-left side). The
Properties window will now show the properties of the table. Expand the Appearance node in the Properties window and set the ColumnStretching property to the name of the Text column (for example, column:c2).
You will get a warning about running a page that is part of a task flow. This tells you that you cannot navigate to other pages; to do that, you need to run the task flow itself. In this case, we just want to run the page, so we can ignore this error and click on Yes to run the page.
Once WebLogic has started, a browser window showing your data will open. Resize the window by checking if the Text column expands and contracts. Also, note that you can re-order the columns by dragging the column headers, and you can change the sorting by clicking on the column headers.
You might want to change the initial column size for some of the columns—to do this in JDeveloper, select an af:column element in the main window or the structure panel and change the Width value (under the Appearance heading) in the Properties window.
Referring to the drawing of the tasks page, we can see that two groups of items are missing: the search criteria at the top and buttons at the bottom.
JDeveloper makes it very easy to create items that represent bind variables. If you expand the
AllTasksVO1 node, as shown in the following screenshot, you will see all of the attributes in the view object, as well as a node called Operations. If you expand the Operations node, you will see a number of standard operations that all view objects offer. One of these operations is ExecuteWithParams, and if you expand this completely, you will see the bind variables defined in the view object (
To lay out the search criteria horizontally as required by the user interface sketch, we will use a Panel Group Layout. Add this (from the Layout section of the Components window) to the top facet. In the Properties window, set the Layout property to Horizontal to get the contents (the various search criteria) arranged horizontally.
For tips on the ADF basic layout, refer to the Oracle white paper, ADF Faces Layout Basics, available at http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adffaceslayoutbasics-2046652.pdf.
The first criterion is the person responsible for the programme. To add this criterion to the page, drop the
pResponsible parameter onto the
Panel Group Layout in the top facet, as shown in the following screenshot:
Leave Base Data Source as variables and click on Add to add a new List Data Source. Choose the
PersonLOV1 view object instance as the source and click on OK. In the table in the middle of the dialog, select
PersId as List Attribute (the value that is bound to the variable). At the bottom of the dialog, choose Initials in the Display Attribute dropdown and set "No Selection" Item to Blank Item (First of List); then click on OK.
Set the Label property for the Property Inspector dropdown in the lower-right corner to
We're taking a shortcut here and hard-wiring a user interface string in. In a real-life application, this should be placed in a resource bundle (see Appendix, Internationalization).
The second criterion is the name of the programme. To add this, first change the Design view of the
TaskPage by clicking on the Design tab at the bottom of the window. From the list of parameters (under ExecuteWithParams), drag the
pProgramme parameter onto the Panel Group Layout next to the
pResponsible drop-down list and again, drop as Single Selection, ADF Select One Choice. Again, leave the Base Data Source unchanged and click on the Add button next to List Data Source. This time, choose the
ProgrammeLOV1 view object instance as the data source for this drop-down list and set List Attribute to
ProgId. Then, set Display Attribute to Name and again set "No Selection" Item to Blank Item (First of List). Then, click on OK. In the Property Inspector, set the Label property to
If the two drop-down boxes are below each other and not next to each other, it's probably because you have accidentally dropped one of them outside the af:panelGroupLayout component. JDeveloper will show you a little red exclamation mark, as shown in the following screenshot:
The easiest place to fix this is in the Structure window in the bottom-left corner of the JDeveloper window. Grab the af:selectOneChoice component that is not indented under the af:panelGroupLayout component. Your Structure window should look as shown in the following screenshot:
The last criterion is the search text that is matched with the Text column. Drop the
pName parameter next to the
pProgramme parameter, and this time, drop it as Text and ADF Input Text w/ Label. Set the Label propertyto Text.
Finally, you need to create a button that actually executes the search. To achieve this, simply drag the ExecuteWithParams operation (the green gearwheel icon) onto the page inside the Panel Group Layout next to the three search criteria. As this is not a data element but an operation, your drop choices are different. Choose Operation and ADF Button. The default text on the button is the name of the operation (
ExecuteWithParams). In the
Property Inspector panel in the bottom-right corner of the JDeveloper window, change the
Text property to
In the latest version of JDeveloper 12c that was available at the time of writing this book (126.96.36.199.0), JDeveloper sets an inappropriate default when you create a list binding for a parameter as we did for
pProgramme. It can be argued whether this is a bug or not—hopefully, this default will change in future versions of JDeveloper.
This screenshot shows all of the connections from the user interface to the data model. You don't need to understand everything here as you are starting out with ADF, but you will be returning to the binding view more often as you master ADF and want to implement more sophisticated features.
Right now, you just need to select the
pResponsible list binding in the left-hand side Bindings box, and in the Properties window, open the Other node and set SelectItemValueMode to <default> (ListIndex), as shown in the following screenshot:
To make sure we got everything correct, let's run the page again. Right-click anywhere on the TaskPage and choose Run from the pop-up menu. This redeploys the application to the built-in WebLogic server, but as WebLogic is already running, your page should appear quickly this time.
Play around with the drop-down lists and try different values in the text search field. Each time you click on the search button, the table should update accordingly.
We can now retrieve data from the database and edit it on the screen. However, we haven't yet created a way to commit these changes to the database. For this, we will choose an operation at the application module level. The ExecuteWithParams operation belonged to the
AllTasksVO1 view object. However, if you collapse all of the view objects, you will see that the
EditTaskServiceDataControl view object also has an Operations node with the Commit and Rollback operations, as shown in the following screenshot:
Before you drag these operations onto your page, drop a Panel Border Layout in the bottom facet of the page. If you refer to the sketch of the user interface, you'll see that we need some buttons (OK to save data and Cancel to revert to the previous values) on the left-hand side and the Timeline button on the right-hand side. Because a Panel Border Layout has a number of facets along the edge, it is a good component to ensure the layout. However, since it does not offer a way to control orientation, we need another component to arrange the OK and Cancel buttons.
Using the Structure window for arranging layout containers
When you have multiple containers within one another, drop them onto the Structure panel in the lower-left corner of the JDeveloper window. This part of the JDeveloper UI will present layout components in a tree structure, making it much easier to control where you drop components.
In the Structure window, expand the af:PanelBorderLayout component that you just added and drop a Panel Group Layout on the Start facet. In the Property Inspector on the lower-right in the JDeveloper window, set the Layout property of this Panel Group Layout to horizontal.
Start or Left?
You will notice that some elements have both a Left and Start facets. In Western languages, these will be placed on the same side of the screen. But because ADF actually supports right-to-left languages, there is a difference. Elements placed in the Start facet will automatically be shown on the right-hand side if the user runs the application with the language set to a right-to-left language, such as Arabic.
Then, drag the Commit and Rollback operations from the Operations node of
EditTaskServiceDataControl onto this Panel Group Layout, and drop them as ADF buttons. The Structure panel should look as shown in the following screenshot. For both of the buttons, use the Property Inspector to set the text (to OK and Cancel) and clear the content of the
Disabled property (under Behavior) to ensure that both buttons are always active.
Run the page again, checking that your buttons are placed where you want them to be. Then, make some changes to the data and click on OK. Use a database tool to verify that your changes are committed to the database, or close the browser and run the application again to verify that your changes are actually stored.
We'll get back to the navigation button when we have built the other page.
To create the scheduled tasks page, go back to the
xdm-poc-flow page flow. If you have closed the page flow window, you can find it again in the application navigator in the top-left corner in the JDeveloper window under Web Content | Page Flows.
Note the difference between the TaskPage and the SchedulePage icons, as shown in the following screenshot. The TaskPage icon now has a solid border and shows a document icon to illustrate that a TaskPage actually exists. The SchedulePage icon still has a dashed lower edge and a pixelated lower half to show that the page doesn't exist yet.
Double-click on the SchedulePage icon and then click on OK to create the page. JDeveloper remembers the settings you selected the last time you created a page.
Again, we start by dragging a Panel Stretch Layout component onto the page from the Components palette.
Under Data Controls, open the
ScheduledTaskServiceDataControl node and drag the
PersonsVO1 view object instance onto the center facet and drop it as Gantt | Scheduling. The Create Scheduling Gantt dialog appears, as shown in the following screenshot:
Resource Id: PersId
Tasks Accessor: ScheduledTasksVO
Task Id: TaskId
Start Time: StartDate
End Time: EndDate
Under Table Columns, remove the extra columns, leaving only
LastName. Then, click on OK. You will see a graphical representation of a scheduling Gantt chart.
You might see both
ScheduledTasksVO1 in the Tasks Accessor list. Select
ScheduledTasksVO and not
ScheduledTasksVO1. You can get from one view object to another in two ways: by referring to the view object instance name and by referring to the code method (the accessor) that gets built when you define the view link. The Gantt components need the accessor.
Click on the chart and then go to the Properties window to set values for the StartTime and EndTime properties (from
2014-10-31 so that it matches the sample data). The Gantt component does not automatically scale to the dates used, and making it do so involves a bit of code—we have chosen to leave this functionality out of this Proof of Concept.
Right-click anywhere on the page and choose Run to see the actual values in the browser and play around with the capabilities of the Gantt chart component. We are using it in default configuration here, but there are many customization options. Refer to the Help section (press F1 with the Gantt component selected) or the documentation for a full description of this powerful component.
The last thing that we need to add to the Proof of Concept application is the navigation feature between the pages.
TaskPage and look at the Structure window. Open the af:panelStretchLayout, then the bottom facet, and then the af:panelBorderLayout. Find the facet called End and drag a Button component from the Components window (in the top-right of the JDeveloper window) across and drop it into this facet. In the Property Inspector, set the Text property to
Timeline, and under Action, select goSchedule.
Finally, we need to drop a Spacer layout component from the Components palette directly onto the af:panelBorderLayout. Your Structure panel should now look like the one shown in the following screenshot:
The reason we need the Spacer component is that ADF automatically optimizes the page and doesn't show any facets that do not have content. So, if the Panel Border Layout doesn't contain anything, the middle part isn't shown and the Start and End facets are right next to each other. With the spacer in place, the central part will take up all of the available space, pushing the Start facet to the left and the End facet to the right.
Now, open the
SchedulePage. Drag a Panel Group Layout into the Bottom facet and set the Layout property to horizontal and the Halign property to right. Then, drop a Button onto the Panel Group Layout, and set the Text to Overview and Action to goTask.
To test the navigation, you can now run the entire task flow. Open the
xdm-poc-flow task flow, right-click anywhere on the window, and click on Run. Your application starts with the default activity (
TaskPage). Check if you can use the Timeline button to go to the
SchedulePage and the Overview button to go back.
In this chapter, we discussed what a Proof of Concept is and why you need it. You got a very brief introduction to the ADF architecture and saw or built a Proof of Concept application using the entire ADF technology stack, including the advanced Gantt chart component.
You are ready to go to your boss and demonstrate what you can do with ADF. If he or she agrees that ADF is the right tool, your next step will be to produce an overall design and estimate how long it will take to build the next generation of destination management software. This is discussed in Chapter 2, Estimating the Effort.