The schemas assigned to the workspace you are currently logged into define the choice of schemas that can be used as the parsing schema. When you create a workspace (as an APEX administrator), you must specify whether to use an existing schema or create a new one, as shown in Figure 1-1. If no other schemas are assigned to the workspace, you will be able to select only this schema as the parsing schema when you create your application.

Figure 1.1. Creating a new workspace

This means that if you already have an existing schema with a lot of objects you'd like to access, you can select that schema. Then, any applications that are created within the schema will be able to access those schema objects directly. This way, you can create an application in APEX that provides a front end to existing data very quickly.

Although you can select only a single schema during the provisioning of the workspace, extra schemas can be assigned to the schema later on. After these additional schemas have been assigned to the workspace, they are available to workspace developers to use as the default parsing schema when they create an application within that workspace.

If you choose to create a new schema during the provisioning of the workspace, a new tablespace and corresponding datafile will be created for that schema automatically. The disadvantage is that the tablespace and datafile will have nondescriptive names, such as APEX_1400423609989676 and APEX_1400423609989676.dbf. Moreover, if you later decide to remove the workspace, that tablespace and datafile will not be deleted. If you regularly provision and delete a lot of workspaces, you can end up with many tablespaces and datafiles cluttering up your disk (and perhaps being unnecessarily included in your backups).

For small developments or evaluation, it may be fine to create a new schema through the APEX wizard. However, from a maintenance point of view, this approach often increases the difficulty in correlating schemas, tablespaces, datafiles, and workspaces because of the nondescriptive names. While this may not be a primary concern to you as a developer, it can be critical to how quickly the DBA is able to restore your schema from a backup if necessary.

Generally, for larger developments, if you are not using an existing schema, you may find it beneficial to manually create the tablespace and schema yourself, using a tool such as Enterprise Manager. For example, you can create a tablespace called APEXDEMO, which has a single datafile named APEXDEMO01.dbf that's allowed to grow to 2GB. You can then create a user APEXDEMO that has the APEXDEMO tablespace as its default tablespace. Figure 1-2 shows how the schema would look after being created in Enterprise Manager.

Figure 1.2. Creating a schema in Enterprise Manager

You could now create a workspace named APEXDEMO and select the APEXDEMO schema you just created in Enterprise Manager, as shown in Figure 1-3. This naming scheme ties together your workspace with the underlying schema and related tablespace and datafiles. If you should accidentally drop some tables (forgetting for the moment about the recycle bin in Oracle Database 10g / 11g), you can use RMAN to recover them easily, since their schema and tablespace will be obvious.

Figure 1.3. Creating a workspace using an existing schema

Although the APEX administrator can view reports that show which schemas and tablespaces particular workspaces are using, adopting a sensible naming convention makes it easier to get this information. For example, the DBA could look at a tablespace called APEXDEMO and be able to understand the purpose of that tablespace, which would not be clear from a generic tablespace name like APEX_1400423609989676.

Once the workspace is provisioned, additional schemas can be assigned to it. For example, you can create an APEXDEMO_TEST schema in Enterprise Manager, log in as the Application Express instance administrator, choose Manage Workspaces

Figure 1.4. Adding a schema to a workspace

Now the workspace administrator can specify which application developers can use the new schema (or, indeed, any of the assigned schemas). Figure 1-5 shows an example of a new developer account being created. By default, the developer will be able to access both schemas (APEXDEMO and APEXDEMO_TEST), since both schemas have been assigned to this workspace.

Figure 1.5. Creating a new developer with access to all assigned schemas

When this developer logs into the workspace, he or she can see the list of schemas that are available by clicking on the Administration

Figure 1.6. Schemas available to the developer

Figure 1.7. Selecting a default parsing schema for an application

Generally, workspaces should be used to group together applications that are related. In other words, if you have a number of developers collaborating on applications that are related to each other and operate on the same data and schemas, ideally you'd create a workspace specifically for those applications.

It is possible, using multiple schemas assigned to a workspace, to establish a development/testing/live environment all within the same workspace. For example, you could create a single workspace that has a schema for development, a schema for testing, and a schema for live objects and data. You could then have three copies of your application: one pointing to the development schema, one to the testing schema, and one to the live schema. However, with this approach, it is all too easy to become confused about which schema you are operating in, with potentially disastrous effects.

It's best to create separate workspaces for development, testing, and live environments. This forces you to specifically log in to an environment, and helps to minimize the risk of making application or schema changes in the wrong environment. The APEX environment helpfully displays which workspace you are logged in to (and which user you are logged in as), so it definitely pays to double-check this information before you perform any drastic operations.

You also need to consider how the development, testing, and production environments will be staged. You may have each environment running on a different database instance (for example, a development instance, a testing instance, and a production instance). If you have only one database instance, it is possible to have the three (or two if you choose to forgo the testing environment!) environments all installed on the same database instance.

When moving an application from one APEX instance to another (instance here refers to a database with the APEX software installed), you need to have created the workspace on the destination instance. The instance administrator can choose to either create the workspace manually or export the existing workspace from the source instance. Exporting the workspace creates a file containing the SQL needed to re-create that workspace, and the instance administrator can then import that SQL file to the destination instance. Figure 1-8 shows the APEXDEMO workspace being exported. Note that you can specify a file format to use (either UNIX or DOS), which will determine the newline sequence used in the file.

Figure 1.8. Exporting a workspace

The advantage of using a workspace export file is that this also re-creates all the users and developers created within that workspace, so it's a quick way of migrating all the existing users (and their permissions) to a new server. It also demonstrates an advantage of using the built-in users. If you use another method to authenticate your users, you'll need to handle their migration manually. Listing 1-1 shows the contents of the file that is created by exporting the APEXDEMO workspace.

set serveroutput on size 1000000

set feedback off
-- Company, user group and user export
-- Generated 2006.07.17 12:58:25 by ADMIN
-- This script can be run in sqlplus as the owner of the Oracle flows engine.
begin
   wwv_flow_security.g_security_group_id := 1635127392255802;
end;
/
----------------
-- W O R K S P A C E
-- Creating a workspace will not create database schemas or objects.
-- This API will cause only meta data inserts.
prompt Creating workspace APEXDEMO...
begin
wwv_flow_fnd_user_api.create_company (
  p_id                      => 1635220613255830,
  p_provisioning_company_id => 1635127392255802,
  p_short_name              => 'APEXDEMO',
  p_first_schema_provisioned=> 'APEXDEMO',
  p_company_schemas         => 'APEXDEMO:APEXDEMO_TEST'),
end;

/
----------------
----------------
-- G R O U P S
--
prompt  Creating Groups...
----------------
-- U S E R S
-- User repository for use with apex cookie based authenticaion.
--
prompt  Creating Users...
begin
wwv_flow_fnd_user_api.create_fnd_user (
  p_user_id      => '1428202658421752',
  p_user_name    => 'ADMIN',
  p_first_name   => '',
  p_last_name    => '',
  p_description  => '',
  p_email_address=> '[email protected]',
  p_web_password => '1E6287A65491647783288E3C9E1A87D1',
  p_web_password_format => 'HEX_ENCODED_DIGEST_V2',
  p_group_ids    => '',
  p_developer_privs=> 'ADMIN:CREATE:DATA_LOADER:EDIT:HELP:MONITOR:SQL',
  p_default_schema=> 'APEXDEMO',
  p_account_locked=> 'N',
  p_account_expiry=> to_date('201011011826','YYYYMMDDHH24MI'),
  p_failed_access_attempts=> 0,
  p_change_password_on_first_use=> 'Y',
  p_first_password_use_occurred=> 'N',
  p_allow_app_building_yn=> 'Y',
  p_allow_sql_workshop_yn=> 'Y',
  p_allow_websheet_dev_yn=> 'Y',
  p_allow_team_development_yn=> 'Y',
  p_allow_access_to_schemas => ''),
end;
/
begin
wwv_flow_fnd_user_api.create_fnd_user (
  p_user_id      => '1437223003555234',
  p_user_name    => 'TGF',
  p_first_name   => '',
  p_last_name    => '',
  p_description  => '',
  p_email_address=> '[email protected]',
  p_web_password => 'D72DA6B4C47475A502A29CA604ACCCBC',
  p_web_password_format => 'HEX_ENCODED_DIGEST_V2',
  p_group_ids    => '',
  p_developer_privs=> 'CREATE:EDIT:HELP:MONITOR:SQL:MONITOR:DATA_LOADER',
  p_default_schema=> 'APEXDEMO',
  p_account_locked=> 'N',
  p_account_expiry=> to_date('201011011848','YYYYMMDDHH24MI'),
  p_failed_access_attempts=> 0,

p_change_password_on_first_use=> 'N',
  p_first_password_use_occurred=> 'N',
  p_allow_app_building_yn=> 'Y',
  p_allow_sql_workshop_yn=> 'Y',
  p_allow_websheet_dev_yn=> 'N',
  p_allow_team_development_yn=> 'Y',
  p_allow_access_to_schemas => ''),
end;

When possible, you should use workspace exports. They enable you to rapidly create a copy of an existing workspace and reduce the chance that you'll forget to create a particular user or developer.

An application developer (or workspace administrator) can export an application from the Application Builder interface. This creates a file similar to the workspace export file, in that the file will contain all the statements necessary to create the metadata required for the application. However, the application export file does not contain the DDL to create any of the database objects your application uses, nor does the application export file contain any data from the database objects that your application uses. Such data would normally be handled with specialized data-loading tools, such as the import and export utilities, or copied over a database link.

You can use the APEX export options, shown in Figure 1-9, to affect the file that is created. For the most part, you won't need to change application export settings. However, you should understand what each of these options do. Here are descriptions of some of the more useful options:

Figure 1.9. Exporting an application

An important consideration is whether you want developers to be able to access your application when it is imported to the target server. There is a trade-off between the added security you gain by exporting the application as Run Application Only versus not allowing your developers to access and debug the application via the Application Builder.

When you set an application to Run Application Only, you lose the ability to debug (by changing the NO in the URL to YES) and trace that application (by adding p_trace=YES to the URL). Generally, you want to set your production applications to Run Application Only, so that end users can't gain direct access to debug information that they shouldn't be able to see.

APEX applications can include references to many different types of static files, including Cascading Style Sheets (CSS), images (JPG, GIF, and so on), JavaScript libraries, and Flash movies. You can reference these static files in two ways:

Both methods have advantages and disadvantages, and you should be aware of how each method will affect your application. Whether you choose to store files in the file system or in the database ultimately comes down to how you intend to manage those files and whether they need to be used by other external systems.

<img src="#WORKSPACE_IMAGES#logo.jpg"></img>

<img src="wwv_flow_file_mgr.get_file?p_security_group_id=16&p_fname=logo.jpg"></img>

Every application in APEX has a unique identifier—an application ID—assigned to it. This ID is used to identify the application and the associated metadata within the APEX repository.

When you move applications between different APEX environments, such as between your development and test environments, you might encounter problems if you've hard-coded any references to values that may be different in these environments. Unless you can be absolutely certain that the application ID and any other references are exactly the same in the different environments, you shouldn't hard-code any of these references.

You can avoid hard-coding the application ID by using the APP_ID substitution string. Here's an example of a typical URL where the application ID (112) has been hard-coded:

f?p=112:1:&APP_SESSION.:

If you import your application into an APEX environment that already has an application that uses the same application ID, forcing you to use a different ID, you may forget to update your hard-coded references. In that case, your links will point to the wrong application.

To avoid this, you should use the APP_ID substitution string, which will be replaced with the actual ID of your application at runtime. Using this substitution string, the URL now looks like this:

f?p=&APP_ID.:1:&APP_SESSION.:

This makes your application more portable between APEX environments.

Although it is not common for pages to be renumbered, you can also avoid having to hard-code a page ID by using the APP_PAGE_ID substitution string. This can be useful where you have a branch on a page that branches back to the same page.

A page within an application can also have an alias defined for it. For example, you may give page 1 the alias of HOME, as shown in Figure 1-10. Now, rather than using a URL such as this:

f?p=&APP_ID.:1:&APP_SESSION.:

you can use this URL:

f?p=&APP_ID.:HOME:&APP_SESSION.:

Figure 1.10. Defining an alias for the page

By using the alias in the reference, you'll be able to renumber the pages and the URL will still be pointing to the correct page.

You should use substitution strings to avoid hard-coding any references to resources (such as style sheets) in templates and HTML regions. This will give you great flexibility to change the location of those resources, whether they are uploaded into the database or are stored in the file system. For example, if you stored all your images in the database by uploading them through the Application Builder interface, you might refer to a particular image file like this:

<img src="#APP_IMAGES#logo.gif" type="image/jpeg" />

At runtime, this will be expanded to reference the download procedure that is used for accessing static files that have been uploaded into the database. The text that is substituted at runtime will be something like this:

wwv_flow_file_mgr.get_file?p_security_group_id=986113558690831&p_flow_id=112&p_fname
=logo.gif

In this section, I described #WORKSPACE_IMAGES# and #APP_IMAGES#. The simple difference between the two is that workspace images are available to any application in a workspace while application images are available only in the application to which they're assigned. If you want to assign an image to an application, you specify the application name during the upload process. If you don't specify an app name, the image will be available to all applications in the workspace.

However, if you now wanted to store the images in the file system rather than in the database, you'd need to change every reference like this one to use a different path to the file.

To simplify and minimize the number of changes you'll need to make, you can define a substitution string that will be used in place of the #APP_IMAGES# substitution string. You can find the Substitution Strings section on the Application Definition page in the Shared Components part of the Application Builder, as shown in Figure 1-11. When you define the substitution string IMAGE_PATH for the value #APP_IMAGES#, the URL then looks like this:

<link rel="stylesheet" href="&IMAGE_PATH.logo.gif" type="text/css" />

Figure 1.11. Defining the alias to reference the #APP_IMAGES# substitution string

Effectively, this creates a substitution string that references a substitution string. At runtime, this will be expanded to reference the same download procedure that was used before. The advantage of using this technique is that if you later decide to store the static files in the file system, rather than storing them within the database, you can simply change the value of your substitution string to reflect the new location, Figure 1-12 shows the substitution string modified to use a reference to the file system instead.

Figure 1.12. Changing the substitution string value to use the file system

This greatly reduces the number of references you'll need to change when moving your application between different APEX environments where the static files are stored in different locations, Figure 1-13 shows how the substitution string would be set in the development environment.

Figure 1.13. Substitution string set in the development environment

The publish/subscribe feature allows you to reuse certain common components among applications. You can define your component in an application, and then other applications can reference that common component by subscribing to it. Any changes that are made to the master component can then easily be incorporated into the applications that subscribe to the component.

Changes can be propagated from the master component to the subscribing component in two ways:

The following components can make use of the publish/subscribe feature:

When you create any of these component types, you have the option of subscribing to an already existing component of the same type. For example, suppose you create a master application that has a named List of Values (LOV) component that uses the following query:

select ename d, empno r
from   emp
order by 1

Figure 1-14 shows the results of using this LOV in a select list.

Figure 1.14. Using the master LOV in a select list

In another application within the same workspace, you can create a new LOV and choose to create it based on an existing LOV, as shown in Figure 1-15. The LOV creation wizard will then allow you to select which application (in the same workspace) should be used to list the available LOVs to subscribe to, as shown in Figure 1-16.

Figure 1.15. Creating an LOV that will subscribe to the master LOV

Figure 1.16. Copying the LOV from the master application

Once you've selected an application, the LOVs available in that application will be displayed, as shown in Figure 1-17, allowing you to copy and subscribe to them.

Figure 1.17. Subscribing to the master LOV

If you now create a select list in the application that uses the LOV you've subscribed to, you will see the same list of employees displayed in the master application, as shown in Figure 1-18.

Figure 1.18. A select list based on the subscribing LOV

If you decide you want to change the definition of the LOV so that the employees are listed in descending alphabetical order, you can go back to the master application and change the query as follows:

select ename d, empno r

from   emp

order by 1 desc

At this point, the master application would display the employees in descending alphabetical order, while the application that subscribes to the LOV would still display the employees in ascending order. To update the subscribing LOV, you need to either publish the changes from the LOV in the master application, as shown in Figure 1-19, or refresh the LOV in the subscribing application, as shown in Figure 1-20.

Figure 1.19. Publishing the changes from the master LOV

Figure 1.20. Refreshing the subscribing LOV

After you either publish the changes from the master application or refresh the subscribing LOV, the select list in the application will use exactly the same query that was defined in the master application. Figure 1-21 shows the select list now displaying the employees in descending alphabetical order.

Figure 1.21. Subscribing LOV refreshed with the master LOV

The publish/subscribe functionality makes it far easier to maintain consistent appearance and behavior across common applications. You could create a single application that's used as the master for all of your common applications, and then make changes to the common components in the master application and synchronize the changes to the other applications by publishing from the master application or refreshing from individual applications.

To ensure that your applications and code are as portable and reusable as possible, you should strive to keep the data itself distinct from its presentation. This means that in general you shouldn't embed HTML markup into the data-retrieval process. For example, suppose you want to display employee names in bold in a report. You could use a query like this:

select '<b>' || ename || '</b>' as ename, deptno, sal from emp

However, it's better to keep the HTML markup out of the query. You could use a custom report template or use the column formatting section within the report attributes to apply some CSS formatting to the individual column. Then the query to bold the names would look like this:

select ename, deptno, sal from emp

Even in this simple example, it's far easier to see at a glance exactly what this query is doing. You can also change the way the data is presented without needing to modify the query definition.

By keeping the HTML markup out of the query, you may find that your application performs better if you use the query in multiple places. Because the query is already stored in the shared pool, Oracle can take advantage of this by soft-parsing the query. If you embed the HTML markup in the query, Oracle will treat two queries as being different, even if only the embedded markup is different. For example, this query:

select '<b>' || ename || '</b>' as ename, deptno, sal from emp

would not be considered the same query as this one:

select '<i>' || ename || '</i>' as ename, deptno, sal from emp

If you run the first query and then the second query (for the first time), Oracle won't find the second query in the shared pool. It would need to hard-parse the query, which would be more CPU-intensive than if it had found the query in the shared pool (and therefore could skip the hard-parse).

Whenever you find yourself including HTML in a query, rethink your approach. Consider how you can use SQL features (such as DECODE, NVL, and so on) to add conditional logic to a report template to distinguish how different columns or rows should be displayed.

If you want to display the same page element on all or multiple pages of your application, consider making use of page zero. When you place a page element on page zero, that element can be seen on all other pages of your application. By including some conditional display logic, you can restrict the element to appear only on certain pages.

A common use for page zero is to include a navigational menu in an application. You can create a region on page zero that contains the menu, which then appears on every page. You can also include a region that contains a navigational menu for administrators. You would include a conditional display that shows this menu only if the application user is an administrator.

By using page zero, you can centralize common components and functionality within your application. This also leads to a more consistent look and feel, since you can control the layout of the elements in a single place.

To get the maximum benefit from the Team Development tools, it is important to understand the interrelationships among its five components. Features and milestones are the anchor components in a development project. Milestones are just what you'd think—a date that has some significance to the project. Once a milestone is defined, it can stand alone or be assigned to features, to dos, and bugs. Features are a little more complex since milestones, bugs, and to dos can be associated with a feature. In addition, one feature can be the parent of another. This allows for an endless hierarchy of features, which is why planning is important. You don't want project management to be more complicated than the development process.

Figure 1-24 shows how you could build a hierarchy of features, bugs, to dos, and milestones with several parent-child relationships. Figure 1-25 shows a simplified method of managing a project. If you equate features to forms or reports, you can see that it's easier to track features, bugs, to dos, and milestones using the simplified method.

In any case, the Team Development tool offers managers and developers a centralized, web-based repository for storing bug reports, user requests, requirement changes, and so forth. This is a significant improvement over the traditional methods for recording this type of information: verbal conversations, handwritten notes, e-mail, etc. Since the Team Development interface is web-based, it can be used by anyone, whether APEX is being used for development or not.

Figure 1.24. Possible feature hierarchy

Figure 1.25. Recommended feature hierarchy

To enable Team Development for a project, the team lead should prepare by identifying the main functions of the application and recording them as features. Specific forms and reports are good candidates to record as features since users routinely report problems and request changes at these levels. In addition, if any milestones are known, they too can be recorded. From that point on, to dos and bugs should be recorded and associated to a feature or a milestone. As new features are added, they should be recorded as well.

A simple workflow for setting up Team Development would include the following:

As the project progresses, new bugs and to dos can be assigned and the status of completed tasks can be updated.

To create a feature, click on the Features icon on the Team Development dashboard and then click the Create button. Figure 1-26 shows the Feature entry screen. It is important to note that this form allows you to not only create a feature, but also to populate LOVs, which are used throughout the Team Development system. Fields used to build LOVs are:

Because the data entered into these fields is accepted without validation, it can easily become polluted. Please note that the "Release" LOV is populated using this form. If Team Development is to be used effectively, data like Release numbers must be tightly controlled. For this reason, it is recommended that access to the Create Feature page be restricted to team leads.

Figure 1.26. Create Feature form

The following LOVs are prepopulated at installation and can't be changed via the Team Development interface:

While many of the fields on this form accept free-form text, Feature Status does not. It is used, as you will see later, to aid in project status reporting. The remaining attributes of this form are self-explanatory and are common to most project management methodologies.

Once the testing process begins, your users will inevitably begin reporting bugs. The Bug form in the Team Development interface is used to record and manage this information. The Create Bug form, shown in Figure 1-27, is similar in functionality to the Create Feature form. As noted, bugs should be associated with features that equate to a form, report, etc.

Figure 1.27. Create Bug page

To dos are similar to bugs in that they are a record of some activity that needs to be done by some date. You could consider a to do as anything except a bug. Figure 1-28 shows the Create To Do page. Determining whether to use the Bug page or the To Do page is up to the team lead. As all developers know, testers often report bugs that may actually be requests for new or changed functionality. In such cases, the team lead may want to create a To Do so that the development team can address the issues appropriately. The main difference between these two objects is that the Bug page can record much more detailed information about the context of the issue.

Like the Create Feature page, the Create Bug and To Do pages contain free-form text fields, LOVs, and fields used to populate LOVs. Using the recommended project management process, a bug or to do would be created and minimally assigned to a feature and to a developer.

Figure 1.28. Create To Do page

It is worth noting that to dos, like features, can be created in a hierarchical fashion. Although this is a powerful feature, it does allow complex hierarchies, which are difficult to track and manage. At least in the beginning, it is recommended that the depth of to do (or feature) hierarchies be kept to one or two levels.

A milestone is a significant date within a project plan. It can signify the required completion date of some unit of work, a business critical date like the end of a fiscal year, or something unrelated to the project like a public holiday. The Create Milestone page, shown in Figure 1-29, allows you to create a milestone, which can then be associated to a Feature, Bug, or To Do.

Figure 1.29. Create Milestone page

Once a milestone is set, it will show up on its assigned date on the project Calendar as shown in Figure 1-30. The annotation of the milestone (November 12 on the Calendar) is actually a hyperlink that, when clicked, causes the Edit Milestone page to be displayed.

Figure 1.30. Project Calendar

Milestones can stand alone or can be assigned to any or all of the project's features, bugs, or milestones. While this can be beneficial in managing a project, it does require the team lead to be diligent in determining how to associate milestones with other objects. It is important to note that any feature, bug, or to do can be assigned only one milestone at a time.

New in APEX 4.0 is the ability to quickly create a page that lets users report system issues to the development team lead. While this may sound like a handy feature, I may recommend you avoid it for the following reasons:

I've been writing code and working with users for more than 20 years, and during that time I've followed one simple approach regarding user feedback: without meaning any disrespect, I don't believe what anyone says about an application bug until I see it myself. When you are intimately familiar with a piece of code, no one can describe a bug in that code better than you. If at all possible, I recommend having a lead developer meet with the user community (or their reasonable facsimile) on a regular basis. The developer can then translate users' concerns into actionable items for the development team.

If you decide you want to include a Feedback page in your system, here's is a brief description of how to do it:

Once you complete this process, your users can access the Feedback page from the Navigation Bar (next to the Login / Logout link). An example is shown in Figure 1-31.

Figure 1.31. Feedback page

One more time, though, beware of asking for unfiltered end-user feedback. You'll get it.

Without progress reporting, all the time and effort spent recording features, bugs, and to dos would be a waste of time. APEX 4.0 addresses this reality by providing mainly dashboards to track project activities. The dashboard for each type of work shows progress and status at a glance, but to get more detailed information, additional reports are available. The APEX 4.0 Team Development system does not contain a consolidated report that shows the status of objects across Features, Bugs, and To Dos, but does have a the Team Development home page that contains dashboards for all types of work.

The main drawbacks to the Team Development system's reporting capabilities are:

Despite these drawbacks, it is still possible to effectively manage a project using the Team Development tools.

Feature Dashboard

When accessing the Features dashboard from the Team Development home page, you'll see a graphic that shows the percentage of Features that are complete and additional information on the total number of recorded features. This dashboard is unique in that a feature is considered complete when its status is set to "Functionally Complete – 80%" as opposed to 100% complete for a bug or a to do. The difference in status labels is a little annoying, especially since there is no way to set your own status labels via the Team Development interface. A feature (or a "page" in this example) that is marked "80% Functionally Complete" is shown in Figure 1-32.

Figure 1.32. Feature dashboard

Bug Dashboard

When you access the Bug dashboard from the Team Development home page, you'll see a percentage graphic showing the number of "closed" bugs. A closed bug is one that has a status of "100.Complete." If you have recorded 2 bugs and closed one, the Bug dashboard will show that 50 percent of the bugs are closed. Several additional links on the dashboard, as shown in Figure 1-33, can be used to navigate to the Bug details page.

Figure 1.33. Bug dashboard

To Dos Dashboard

The To Dos dashboard is decidedly different from the Features and Bugs dashboards. While this page does show the completion status of all recorded To Dos as a percentage, it also contains a doughnut-shaped graphic that shows the percentage of to dos assigned to each developer. If you have two developers and each is assigned one to do, the doughnut will be divided in half to show that each developer is responsible for 50% of the to dos. The graphic also acts as a hyperlink for navigating to a report of to dos by developer. Like bugs, to dos must be 100% complete before the dashboard will show a completion percentage. Figure 1-34 shows the To Do dashboard.

Figure 1.34. To Do dashboard

Although it may be difficult to see in gray-scale, the doughnut-shaped graphic is divided in half and is shown in two distinct colors. Clicking either half of the graphic or any of the other hyperlinks on this page results in navigation to the associated to do detail page.

You access the APEX Development Advisor from the Utilities menu of an application home page, as shown in Figure 1-35. You should review each of the Checks to Perform to ensure that you get only the information you need. In the Check Pages section, you can include a comma-separated list of page numbers to scan, or leave this area blank to scan all pages.

Figure 1.35. APEX Development Advisor

The resulting "report" shows all of the areas that don't meet the requirements of the Advisor. Using the example stated above (make sure all fields have help text defined), the Advisor was run on Page 1 of the Buglist application. The resulting APEX Development Advisor report shown in Figure 1-36 identifies a field as having no help text and includes a "View" link to take you directly to the item in question.

Figure 1.36. APEX Development Advisor report

The integrated Code Debugger has a clean, graphical user interface to view detailed application execution details. Debugging can be enabled or disabled for an application using the Edit Application Properties button on the Application Home Page. Once debugging has been enabled, it can be activated at any time during execution (when running in development mode) by pressing the "Debug" button at the bottom of the application page. Clicking the "View Debug" button at the bottom of any page brings up the Debug Message page, as shown in Figure 1-37. This page displays a history of the debug sessions that have been run for this application and their relative time of execution.

Figure 1.37. APEX debug history

Clicking on the most recent debug session identifier opens another window showing the details of that session, as shown in Figure 1-38. The bar graph in the details window shows the execution times of each recorded activity. Hovering your mouse over the bars pops up some help text that describes the activity. Clicking on the bar will navigate to that activity in the debug details.

Figure 1.38. APEX Debugger