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 next:

The View layer is interacting with the user, 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. And the Model layer is representing the backend business services to the View and Controller, 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. And the controller doesn't have to worry about how to store data in the data service, because that is the task of the model.

The backend part consists of a business service layer that implements the business logic and provide some way of accessing the underlying data services. Business services can be implemented as API code written in Java, PL/SQL or other languages, web services, or using 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 file system or data in other systems accessed through an interface.

Entity objects (EOs) takes care of object-relational mapping: Making your relational tables available to the application as Java objects. Entity objects are the base that view objects are 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 your application uses, and this object is responsible for producing the correct SQL statements to insert, update or delete in the underlying relational tables.

The entity objects helps you build scalable and well-performing applications by intelligently caching records on the application server in order to minimize the load the application places on the database.

Like entity objects are the middle-tier reflection of database tables and database views, Associations are the reflection of foreign key relationships between tables. An association represents a connection between two entity objects and allows ADF to relate data in one entity object with data in another. JDeveloper is normally able to create these automatically by simply inspecting the database, but in case your database does not contain foreign keys, you can build associations by hand to tell ADF about the relationships in your data.

While you do not 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.

View objects are typically based on entity objects and you will be using them for two purposes:

The data handling view objects are normally specific for each screen or business service. One screen can use multiple view objects—in general, you need to create one view object for each master-detail level you wish to display on your screen. One view object can pull together data from several entity objects, so if you just need to retrieve a reference value from another table, you do not need to create a separate view object for this.

The LOV view objects are used for drop-down lists and other selections in your user interface. They will typically be defined as read-only and because they are reusable, you will define them once and re-use them everywhere you need a drop-down list on a specific data set.

View Links are used to define the relationships betweens the view objects and are typically based on associations (again often based on foreign keys in the database).

The following figure shows an example of two ways to display the data from the familiar EMP and DEPT tables. The left-hand illustration shows a situation where you wish to display a department with all the employees of the department in a master-detail screen. In this case, you create two view objects connected by a view link. The right-hand illustration shows a situation where you wish to display all employees, together with the name of the department where they work. In this case, you only need one view object, pulling together data from both the EMP and 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 piece of functionality. If your requirements are specified with use cases, there will often be one application module for each major use case. However, multiple use cases can also be grouped together into one application module – indeed, it is possible to build a small application using just one application modules.

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 to build 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 like JavaServer Pages (JSP).

In a JSF application, the user interface does not contain any code, but is instead built from configurable components from a component library. For your application, you will want to use the sophisticated ADF 11g JavaServer Faces (JSF) component library, known as the ADF Faces Rich Client.

One of the great improvements in ADF 11g was the addition of ADF Task Flows.

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 has this), but the controller in ADF Task Flows is the first controller capable of handling large enterprise applications.

An ADF web application has one Unbounded Task Flow where you place all the publicly accessible pages and define the navigation between them. This corresponds to other controller architectures. But ADF also has Bounded Task Flows, which are complete, reusable mini-applications that can be called from the unbounded task flow or from another bounded task flow.

A bounded task flow has a well-defined entry point, accepts input parameters and can deliver 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.

In your task flows, you can define either pages or page fragments. Pages are complete web pages that you can run on their own, while page fragments are reusable components that you place inside regions on pages. An enterprise application will often have a small number of pages (possibly only one), and a larger number of page fragments that dynamically replace each other inside a region. This design means that the user does not see the whole browser window redraw itself—only parts of the page will change as one fragment is replaced with another. It is this technique that makes an ADF application seem more like a desktop application than a traditional web application.

On your pages or page fragments, you add content using layout components, data components and control components:

This screen allows the user to search for tasks by responsible person, program or a free-text search. Data can be updated and saved back to the database:

For simplicity, we will not implement the application menu, but instead just have a button labeled Timeline that invokes UC104.

Your manager would like something such as the Gantt charts he uses to track projects, which shows the tasks assigned to each person on a timeline:

Again, we will not have a menu, just a button for returning to UC008.

To create a view objects for Persons, choose File | New, and in the New Gallery choose View Object. It is a good idea to give your view objects a name that indicates their intended usage as lists of values—for the list of persons, use the name PersonLOV. Leave the data source at Updatable Access through Entity Objects.

In step 2 of the wizard, choose the Person entity object and move it to the box on 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:

In step 3 of the wizard, move the fields you want to the right-hand side—note that the primary key attribute will always be included:

In step 5 (Query), you define the ordering of records by entering initials in the Order By field. Then click Finish to create the view object.

Repeat this procedure to create the two other value list view objects:

To create a view object for tasks, look at the Task Overview and Edit page (UC008) and at the data model. You will 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 TASKS table through the Task entity object.

Create a new view object (AllTasksVO), leaving the data source at Updatable Access through Entity Objects. In step 2 of the wizard, choose the Task entity object and move it to the right-hand side. Because 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 Next two times and choose to order by start_date. Then click Next to get to Bind Variables (Step 6).

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 pResponsible, pProgramme and pText. You can leave the other settings in this step of the wizard at their default values.

When you're done, click the Back button to return to step 5 of the wizard, and add a WHERE clause that uses the bind variables. It should look like this:

 (: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) || '%')

When you are done entering the WHERE clause, click on the Test button to verify that your SQL is valid.

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, and concatenating a wildcard character before and after the parameter value to search for occurrences of the search text anywhere in the database value.

When you click 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 list box. Double-click on the AllTasksVO view object to edit it and choose the Attributes sub-tab. Choose the ElemKey attribute and then click on the green plus sign next to the heading List of Values. The Create List of Values dialog appears:

In this dialog, click the green plus sign to add the List Data Source. Choose the ServiceLOV view object and then ElemKey as List Attribute.

Since we do not want to display the actual key value (ElemKey) to the user, you should click on UI Hints tab, and move the Description attribute to the right-hand box. Uncheck the Include No Selection checkbox, and then click OK.

The Attributes tab also allows you to define some hints to the user interface components about rendering the component. Double-click the StartDate attribute and choose the Control Hints sub-tab. Set the Label Text to Start time, set Format Type to Simple Date and in the Format field, enter the format mask dd-MMM-yy HH:mm.

Click OK and then set a Label Text for the remaining elements, referring to the user interface sketch for UC008 (Format is only used for date and number objects).

To create an application module for tasks, choose File | New and then Application Module. Give the application module a name (for example, EditTaskService). In step 2 of the wizard, expand the tree in the left-hand side and shuttle the AllTasksVO to the right-hand side, together with the PersonLOV and ProgrammeLOV that we need to create the search criteria value lists. This is all you need to do, so you can simply click Finish to close the wizard.

Now you can verify that your application module works the way you expect it to. In the application navigator, 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 Business Components Tester where you can work with all of the view objects that are part of your application module.

Double-click on the AllTasksVO1 view object. A pop-up dialog appears, allowing you to assign values to all the bind variables defined in the view objects. To begin, just click OK to leave all bind variables at the value NULL.

Here, you can page through the existing data as well as insert and delete rows using the green plus and the red cross symbol. 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 data is filtered.

For the scheduling screen, we need two view objects: one for persons, and one for tasks assigned to persons.

We already have a view object showing persons, but this view object only contains initials (because it was intended for the Persons drop-down in UC008). We could create a new persons view object for UC104, but we will change the existing view object instead.

First, you need to change the name of the view object from PersonLOV to PersonsVO to reflect that it is no longer just used for a list of values. Changing 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 references to it:

Next, the view object needs some more attributes. To add these, open the view object by double-clicking on it and choose the Attributes sub-tab. Click the little triangle next to the green plus sign above the attributes and choose Add Attribute from Entity. Do not just click the plus sign—you need to select the little triangle to get access to the Add Attribute from Entity menu item you need:

In the Attributes dialog, add the FirstName and LastName attributes to the Selected list. Then select the new FirstName and click the little pencil icon to edit the attributes. Under Control Hints, set a Label Text. Repeat for LastName.

Then 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. Since we will not be updating tasks either, you can remove the checkbox in the Updatable field here as well. In step 3 of the wizard, you only need to select the StartDate and 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 WHERE clause:

start_date is not null and end_date is not null

Then click Finish.

Since there is a master-detail relationship between persons and tasks, we also need to create a view link. Select File | New and then View Link. Give your view link the name PersonsTasksLink.

In step 2 of the wizard, we need to define the relationship between the two view objects. These are connected by the foreign key PERS_TASK_FK that defines the connection between a person and the tasks assigned to that person. Expand the PersonsVO node on the left and choose PersTaskFkAssoc as the left-hand side of the link. On the right, expand the ScheduledTasksVO node and again choose PersTaskFkAssoc, this time as the right-hand side of the link. Then click Add. You see the source and destination attributes added at the bottom of the dialog box:

You do not need to change any of the remaining settings in this wizard, so you can simply click Next and Finish to close the dialog box.

Create another application module for the UC104 Person Task Timeline screen, giving it the name ScheduledTaskService.

In step 2 of the wizard, first move the PersonsVO to the right-hand side. Then select the Persons1 view object instance on the right and the node ScheduledTasksVO via PersonTaskLink on the left, and click the > button to move ScheduledTasks to the right-hand box:

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 Finish to close the wizard.

Run your new application module in the business components tester. In the left-hand side, you will see the master view object, the view link, and the detail view object. Double-click on the view link to see master and detail records together. When you use the navigation buttons at the master level, you will see different detail records displayed:

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 from blank pages (make sure Blank Page is selected) – but when actually building the real application, we will, of course, be using page templates. Click OK to create and open the page.

There are two ways to place ADF components on a JSF page: you can drag them in from the component palette on the right, or you can drag them in from the data binding palette on the left.

If you drag in a component from the component palette, it is not bound to any data control. This means it has no connection to the data in the ADF business components.If you drag in the data control from the data control 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 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 and EditTaskServiceDataControl.

However, before we start dragging in data controls, we need to place a layout component on the page to control where items are to be placed. If you come from a 4GL background (like 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 to this approach is that it takes a little while to learn to use the right layout components.

For the taskPage, we start with a Panel Stretch Layout. Find this component in the Component Palette in the right-hand side of the JDeveloper window (under the Layout heading) and drop it on the page:

If you expand the Panel Stretch Layout in the Structure Panel at the bottom right of the screen, you will see that it shows a folder-like node called Panel Stretch Layout Facets, and under that additional folder-like nodes called bottom, center, and so on. Many layout containers contain these containers (called facets) that you can place your content in:

If you refer back to the screen design earlier in this chapter, you 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 do not need the start and end facets, but 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, and then open the EditTaskServiceDataControl node. You see the AllTasksVO1 view object. Grab the entire view object and drag it onto the center facet. 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 first Table and then ADF Table from the context menu. The Edit Table Columns dialog appears:

In this dialog box, you can remove the columns that you do not 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 or 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 and click OK. You will see a table component in the middle of your page.

Finally, you need to tell 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 does not 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 Property Inspector in the lower right corner of the JDeveloper window) – it will be something like c3. Then select the entire table (either in the Design window in the middle of JDeveloper or in the Structure Panel at the lower left). The Property Inspector will now show the properties of the table. Expand the Appearance node and set the ColumnStretching property to the name of the Text column (for example, column:c3).

Even though we do not have the search functionality built yet, it is about time that we run some code. Simply right-click anywhere on the taskPage page and choose Run from the pop-up menu. In the log window at the bottom of the JDeveloper window, you can see the WebLogic server starting up. This will take a while.

Once WebLogic has started, a browser window will open, showing your data. Resize the window, checking that the Text column expands and contracts.

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 Property Inspector.

Referring back 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, you will see all 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 fully, you will see the bind variables defined in the view object (pResponsible, pProgramme and pText):

To control the layout of the search criteria, first add a Panel Group Layout (from the Layout Component Palette) to the top facet.

The first criterion is the person responsible for the program. To add this criterion to the page, drop the pResponsible parameter onto the Panel Group Layout in the top facet. When you release it, a context menu appears. From this menu, select Single Selection and then ADF Select One Choice. The Edit List Binding dialog appears:

Leave Base Data Source at variables and click Add to add a new List Data Source. Choose the Persons view object as the source. 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 drop-down and set "No Selection Item" to Blank Item (First of List), then click OK.

In the Property Inspector at the lower right, set the Label property for this drop-down to Responsible.

The second criterion is the name of the program. From the list of parameters (under ExecuteWithParams), drag the pProgramme parameter onto the Panel Group Layout next to the pResponsible drop-down 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. Choose the Programme view object 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 OK. In the Property Inspector, set the Label property to Programme.

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, ADF Input Text w/ Label. Set the Label property to Text.

If you cannot see all the components on the screen, you can grab the bottom edge of the top facet where you added the items, and pull it down.

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. Because this is not a data element, but an operation, your drop choices are different. Choose Operation, 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 Search.

Your objects are probably placed below one another right now. To change this, select the panel group layout that you dropped in the top facet. It can be a bit hard to pick the exact right layout or input component in the design view of the page in the center of the JDeveloper window. Instead, look at the Structure panel at the bottom left of the JDeveloper window:

With the panel group layout selected, look at the Property Inspector in the bottom right-hand corner. Change the Layout property to horizontal to align the search criteria and the button horizontally. If you resized the top facet to see everything, you can make it smaller again.

To make sure we got everything correct, let us run the page again. Right-click anywhere on the taskPage page and choose run from the pop-up menu. Because WebLogic is already started, your page should appear quicker 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 have not 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. But if you collapse all the view objects, you will see that the EditTaskServiceDataControl also has an Operations node with operations Commit and Rollback:

Before you drag these operations onto your page, drop a Panel Border Layout on the bottom facet of the page. If you refer back to the sketch of the user interface, you will see that we need some buttons (OK and Cancel) in the left side, and the Timeline button on the right. Because a Panel Border Layout has a number of facets along the edge, this is a good component to ensure this layout. However, since it does not offer a way to control orientation, we have another component to arrange the OK and Cancel buttons.

In the structure panel, expand the af:PanelBorderLayout component you just added, and drop a Panel Group Layout on the left facet. In the Property Inspector at the lower right in the JDeveloper window, set the Layout property of this Panel Group Layout to horizontal.

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 next. For both buttons, use the Property Inspector to set the text (to OK and Cancel), and delete the content of the Disabled field (under Behavior) to ensure that both buttons are always active:

That is all there is to it—the ADF application module will automatically handle everything to ensure that your changes are either committed to the database or rolled back.

Run the page again, checking that your buttons are placed where you expect. Then make some changes to the data, and click 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 will get back to the navigation button when we have built the other page.

Again, we start by dragging a Panel Stretch Layout component onto the page from the Component palette.

The component we need to implement the graphic representation of tasks assigned to persons is a Gantt chart of type Scheduling.

Under Data Controls, open the ScheduledTaskServiceDataControl node and drag the Persons view object onto the center facet and drop it as Gantt | Scheduling. The Create Scheduling Gantt dialog appears:

Set the fields in this dialog as follows:

Under Table Columns, remove the extra columns, leaving only FirstName and LastName. Then click OK. You will see a graphical representation of a scheduling Gantt chart.

Click in the chart and then go to the Property Inspector to set values for the StartTime and EndTime properties (for example, 2011-10-01 and 2011-10-31). The Gantt component does not automatically scale to the dates used, and making it do so involves a bit of code – we choose 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 (Press F1 with the Gantt component selected) or the documentation for a full description of this powerful component.