C H A P T E R  4

Supporting Technologies

APEX can be viewed as a stand-alone web development tool, as a simple web development framework, and as a complex web development framework. The main difference between the viewpoints is the number of supporting technologies that are used in concert to achieve your desired results.

This chapter lists the technologies that support APEX together with some suggested tools (see Figure 4-1). The technologies are grouped as follows:classification

• Mandatory technologies required to make APEX work: without them, you cannot get started.
• Core technologies required in order for you to evolve from simple “hello world” applications to industrial-grade applications that are functional, robust, maintainable, scalable, and secure. The core technologies are associated with using APEX’s “out of the box” strategy that emphasizes keeping APEX applications well within the boundaries of the APEX declarative environment. You will find that adding the core technologies to your development environment enables you to easily adhere to Agile’s principle of “continuous attention to technical excellence and good design.”
• Extended technologies used to build advanced web features that require expert APEX knowledge, or technologies that are outside of the APEX declarative environment. These technologies are added to an APEX application in response to advanced and sophisticated user requirements.

As you progressively add the mandatory, core, and extended technologies to your development environment, you should be aware that adding the technologies will

• Slow delivery times
• Incur higher costs
• Require larger teams
• Add more complexity and risk

Happily, these issues can be managed effectively with an Agile approach. You just need to move a little bit from the lightweight side of the governance spectrum to a slightly heavier approach. Always remember to add supporting technologies and the required project governance to your environment by using the Goldilocks Principle: “Do not add too much technology, do not add too little technology, add just the right amount.” Following this simple principle requires experience and good judgment. Since you are interested in Agile, I bet you have both attributes.

Figure 4-1. APEX technologies

Mandatory Technologies

Out of the box, APEX is simple; this, of course, directly supports Agile’s principle of “simplicity.” The basic setup requires only four things: a workstation, an Oracle database, APEX, and a rudimentary understanding of SQL. Table 4-1 summarizes these technologies and lists some of the common tools used to implement them.

Table 4-1. APEX Mandatory Technologies and Tools

Mandatory Technologies	Suggested Minimum Toolset
Workstation	Browser: Firefox Monitors: Minimum of two 21-inch monitors
Oracle database and a web server	SQL*Plus APEX SQL Workshop
Oracle Application Express (APEX)	APEX Application Builder APEX Administration
Structured Query Language (SQL)	APEX Application Builder APEX SQL Workshop

Workstation

Software developers spend a huge amount of time sitting at a workstation. The workstation is one of the most important tools in our development environment and one that is often overlooked as an important vector for productivity improvements.

A workstation is an ecosystem that consists of a desk, chair, mouse/trackball, keyboard, lighting, temperature, humidity, computer, reference books, noise, phone, printer, monitor, access to healthy food, access to water, office neighbors, and, in the center of it all, a programmer. Organizing this environment in a healthy way helps programmers to follow the Agile principle “sustainable development, able to maintain a constant pace.” A workstation does not need to be pretty or expensive in order to be effective (see Figure 4-2). The main criterion is the provision of a comfortable and safe working environment.

Figure 4-2. A comfortable workstation

Ergonomics is out of scope for this book; however, I want to comment on one technical productivity tool that I think is important: large monitors. Large workstation monitors are, in my mind, one of the most important technical productivity tools in the web-based software development environment. A simple change to a web application often involves changing code in several files at once. Having two or more large monitors enables a programmer to display all the code snippets at one time so they can be viewed simultaneously. This strategy enables the programmer to see all the code snippets and, more important, their relationships. Case-sensitive variable names can be copied and pasted between applications to avoid subtle bugs. Using large monitors enhances productivity and assists programmers in their effort to follow the principle “continuous attention to technical excellence and good design.” I single out large monitors because they are a relatively expensive part of a workstation setup compared to the other components, like keyboards and mice; some organizations see only the capital cost saving by buying small monitors without researching the ongoing cost due to lost productivity.

For APEX, the only mandatory workstation software is a web browser. You can develop APEX applications by using any of the common browsers on the market today; however, for serious development, I suggest Firefox. A number of plug-ins for Firefox, such as Firebug and the Web Developer toolbar, help you with HTML layouts and developing JavaScript code. There are other browsers, like Chrome, that can be equally effective. The browser landscape is evolving at a horrifically fast pace; it is hard to keep up.

Oracle Database

APEX lives inside an Oracle database; therefore the database is a mandatory tool. There are a number of ways that you can gain access to an Oracle database for APEX development:

• http://apex.oracle.com (free)
• Oracle Database 11g Express Edition (Oracle Database XE) (free)
• Oracle Standard or Enterprise Editions
• Cloud

Apex.oracle.com is a cloud-like free service that lets you sign up for an APEX workspace and schema. It is an ideal way for programmers to “kick the tires” of an APEX environment without investing any time in setup and configuration. The http://apex.oracle.com home page (see Figure 4-3) allows you to easily and quickly sign up for an APEX workspace in a few minutes. The page also contains a set of links that point you to the essential online APEX documentation; I highly recommend having a look at the Application Express Documentation and Oracle by Examples (OBE) links that are under the Getting Started heading. The only software tool you need in this environment is your browser. Note that you may not use this environment for production work; it is strictly used as a learning and demonstration tool.

Figure 4-3. Apex.oracle.com home page

The Oracle Database 11g Express Edition (Oracle Database XE) is a free, small-footprint Oracle database that you can download from

http://www.oracle.com/technetwork/database/express-edition/overview/index.html

Oracle Database XE is ideal for installing on a local workstation. The installation documentation is clear, so most developers have very little trouble getting the database up and running. APEX 4.0.2 is preinstalled and configured and requires no initial setup or configuration work. Upgrading to the most current version of APEX is relatively straightforward and only requires a rudimentary knowledge of SQL*Plus. The upgrade instructions that come with each download version of APEX are reasonably clear; however, the book Oracle Application Express Recipes (Apress, 2011) contains an explicit procedure that is a valuable help when used in conjunction with the upgrade procedure that comes with the downloaded version. This procedure is handy for developers who do not have an extensive DBA background because it is written for developers and explains the steps in detail without making assumptions about the reader’s background.

Loading Oracle Database XE onto your local workstation is especially useful when you are building a custom theme. This strategy allows the template developer to develop and debug a new theme without impacting the rest of the team who are developing the application in a shared workspace. The new theme can easily be copied to the shared development environment and installed into the application that is under development after the new theme is thoroughly tested and debugged in the Oracle Database XE environment.

Many companies already have a licensed copy of an Oracle database. In this case, developers need to work with their DBAs to get the APEX environment set up and configured.

The cloud is now a reality. A number of commercial vendors will sell you access to an Oracle database. To use these services, you need to work with the cloud vendor to get your APEX environment set up and configured. Oracle, at Oracle Open World 2011, announced that it will make APEX itself available for production work in the cloud. Amazon offers an Oracle 11g database in its Amazon Elastic Compute Cloud (Amazon EC2) web service. This is a quick, easy, and cost-effective means of gaining access to a fully functional Oracle 11g database.

Oracle Application Express (APEX)

APEX is a mandatory tool. This is obvious. Good-quality, simple production applications can be built by using only the Application Builder and SQL Workshop modules. All of the absolutely essential aspects of application development are supported within the declarative APEX environment.

Structured Query Language (SQL)

You must have at least an introductory understanding of Structured Query Language (SQL) in order to build APEX applications. As an absolute minimum, you must know only one essential SQL statement:

SELECT * FROM MY_TABLE

This simple SELECT statement is all the code you need in order to build an interactive report. Of course, you will most likely need more than this as you extend your applications. Typically, for relatively simple applications, you can build your Oracle database declaratively by using SQL Workshop. SQL Workshop contains wizards that build tables (see Figure 4-4) and views and takes care of all the required INSERT and UPDATE SQL statements for you. In small and simple applications, most of your SQL coding work will be related to SELECT statements in reports, item defaults, and validations. The query builder (see Figure 4-5) that is built into the Create View Wizard is an excellent example of the fairly sophisticated graphic functionality that is built into the core APEX development platform.

Your skill with SQL must, of course, grow together with the size and complexity of your applications. SQL is a mature technology. Many books and courses will help you learn how to write efficient, accurate, and understandable SQL.

Figure 4-4. SQL Workshop Create Table Wizard

Figure 4-5. SQL Workshop query builder in the Create View Wizard

Core Technologies

The core technologies (see Table 4-2) are not absolutely necessary to build APEX applications; however, you will quickly find that they are required when you want to

• Improve your productivity
• Extend APEX functionality
• Write maintainable applications
• Build large applications
• Adhere to the core values and principles of Agile software development

Table 4-2. APEX Core Technologies and Tools

Core Technologies	Tools
Procedural Language/Structured Query Language (PL/SQL)	APEX SQL Workshop SQL Developer TOAD
Mockups	APEX Application Builder Wireframe and Mockup application
Oracle database	SQL Plus Oracle Enterprise Manager Oracle Application Programming Interface (API)
Database design	SQL Developer SQL Developer Data Modeler
Operating system	Text editor
Security	Lightweight Directory Access Protocol (LDAP) Oracle Single Sign-On (SSO)
Core debugging	APEX Debug APEX Advisor Firefox Developer toolbar add-in

Procedural Language/Structured Query Language (PL/SQL)

PL/SQL is the scripting language that is used by the Oracle database for manipulating data. APEX itself is a PL/SQL application; therefore it is not surprising to find that PL/SQL is one of the core technologies used with APEX.

PL/SQL is used to code business logic. It is a best practice to separate the GUI from the business logic. The separation of GUI and business logic is one of the first steps you take when applying the Agile principle “continuous attention to technical excellence and good design.” In practice, you create one or more PL/SQL packages that contain procedures and functions that contain the business logic. Figure 4-6 shows you a snippet of PL/SQL code that is coded in the APEX Application Builder. The snippet contains business logic that might be handy in other areas, as well as some plumbing code. Figure 4-7 shows the same snippet after the logic and plumbing code have been moved to a PL/SQL package. The only logic left in the GUI is the call to the PL/SQL package plus the exception handling. Exception handling in the GUI is required because the GUI knows the context in which the end user is operating. Having easy access to the GUI components makes it relatively easy to give the end user an error message that makes sense to them and helps them to correct the problem so they can continue working without pestering the help desk.

All data items in the APEX GUI are strings. I have found it handy to push the data-type conversion work into overloaded routines that are paired with routines that do the real business work (see Figure 4-8). This removes plumbing clutter from GUI code. The routines that do the real business work are called with the expected data types—DATE, for example․so they can be called directly from other PL/SQL code without having to worry about redundant data-conversion work or depending on implicit data conversion.

Figure 4-6. Anonymous PL/SQL block in the GUI with business logic

Figure 4-7. Anonymous PL/SQL block in the GUI with business logic moved to a package

Figure 4-8. Use overloaded routines to eliminate data-type conversions in the GUI.

PL/SQL is a sophisticated and powerful procedural language. You thus need an industrial-strength tool for working with that language when doing serious development. The tool must

• Be convenient to use so you can code productively
• Be able to support effective unit testing outside the APEX context
• Have a good debugger so you can produce high-quality code

You have two tool choices from Oracle: SQL Workshop and SQL Developer. There are also third-party tool sets such as TOAD.

SQL Workshop, a module within APEX, is a quick-and-dirty PL/SQL development environment where you can code small and simple routines. It is not an industrial-grade PL/SQL development platform because the development windows in APEX 4.x contain no formatting or debugging functionality.

SQL Developer is a free Oracle tool that has recently evolved into a very effective PL/SQL development environment. It has many sophisticated features that support the full development life cycle.

Several high-quality licensed PL/SQL development tools are available in the commercial market place; TOAD is a good example.

Choosing the tool that is right for your team requires cooperation between developers. Most developers have their favorite tool set, but in a team environment it pays productivity dividends when the team members all use the same tool.

Mockup Tool

Mockups are useful artifacts to employ when you are beginning a software development project or adding a new module to an existing application. The act of building a mockup can be a wonderful design activity that is a delightful and productive collaboration between the software and business teams. Building a mockup collaboratively supports the Agile principle “Close, daily co-operation between business people and developers,” and it is a great vehicle for facilitating knowledge transfer between the two teams.

APEX can be used as a mockup tool. The attractive advantage of this strategy is the fact that the resulting mockup is very close to a working prototype that can quickly evolve into the first version of the application; developers are attracted to this strategy because they are comfortable with the APEX development environment.

The disadvantages of using APEX as a mockup tool are as follows:

• Developing the mockup is a slower process.
• It’s difficult for the business team to actively participate.
• The business team must have access to an APEX development environment.

These disadvantages combine to prevent the business team from taking active part in building the mockup. This point is driven home by Listing 4-1, which shows how you would mock up a simple APEX report; the business users probably would not be comfortable coding this on their own, especially when a large number of columns and rows are required to give a realistic picture of the proposed application.

Listing 4-1. Hard-Coded SQL Used to Mock Up an APEX Peport

A number of wireframe and mockup tools are available in the commercial marketplace. Some are free, and some cost a few dollars. Figure 4-9 shows a mockup of the report from Listing 4-1 together with several other easy-to-use objects that can be placed on the page with simple drag-and-drop technology. Many of the wireframe and mockup tools are file based, so little or no specialized configuration is required. Simple and intuitive interfaces enable both the development and business teams to quickly come up to speed with the tools.

The tool illustrated in Figure 4-9 is Balsamiq, an effective tool that costs less than $100. The Balsamiq mockup can be exported to a PDF file that contains active buttons and links. The active buttons and links allow the application designers to jump to the appropriate mockup page in the same fashion as the finished application; this type of mockup is extremely effective because the PDF file can easily be distributed to a wide audience via a shared drive or through e-mail.

Figure 4-9. A mockup is built using an easy drag-and-drop prototyping tool.

Oracle Database

The Oracle Relational Database Management System (RDBMS) is huge and complex. Happily, APEX developers usually need only concern themselves with the data and programmatic aspects of the Oracle database and can leave most of the “under the hood” configuration and maintenance to professional database analysts (DBAs).

Some of the Oracle database data and programmatic objects that APEX developers typically use are

• Tables, indexes, views, and materialized views
• Foreign keys
• PL/SQL packages
• Code libraries

APEX developers can use SQL Workshop to build and maintain these database artifacts. However, as applications become bigger and more complex, it becomes more efficient to use industrial-grade tools like SQL Developer and TOAD. I personally use a combination of SQL Workshop and SQL Developer for my database development work; I tend to use SQL Workshop to create tables and views and SQL Developer for writing PL/SQL code.

The relationship with the Oracle database that contains APEX is straightforward (see Figure 4-10). The APEX engine is a large PL/SQL application that resides in an Oracle database. The APEX engine creates one or more workspaces that, in turn, contain one or more APEX applications. Each APEX application has a one-to-one relationship with a parsing schema that contains all the database objects the application needs to function.

Figure 4-10. How APEX fits with the Oracle database

Database Design

APEX builds web interfaces on top of an Oracle database. A solid, well-crafted database design is critical to the success of an APEX application. As your APEX applications become more complex, you will need to use professional design tools like SQL Developer Data Modeler or one of its commercial counterparts like TOAD in order to

• Design the database
• Document the design

SQL Developer Data Modeler assists in the development of both the logical and physical designs of your database. The tool automatically generates the SQL statements that create the physical database objects. The tool contains a graphic interface that draws an entity relationship diagram (ERD) and enables you to print it on a large plotter (see Figure 4-11). The ERD is a valuable visual design tool that helps you to design complex data models. It usually evolves through several iterations before it is ready for construction.

Figure 4-11. Oracle SQL Developer entity relationship diagram

Operating System Scripting

APEX usually runs on Windows or Linux servers. The developers who are in charge of promoting applications from the development environment through to the production environments need to become familiar with the operating system scripting tools in order to effectively automate the promotion process.

In general, a simple text editor is the only tool needed to build the operating system scripts. The traditional low-level text editors are notepad.exe for the Windows operating systems and vi for the Unix platforms. There are, however, a huge number of text editors on the market. Some tailor their automatic formatting to specific languages, and many contain language syntax checkers. Automatic formatting and color-coded syntax (see Figures 4-12 and 4-13) help programmers to code quickly and accurately by highlighting a program’s structure and pointing out simple clerical coding mistakes.

A good working knowledge of the operating system command-line environment is also mandatory.

In addition, database tools like SQL Developer have sub-features that compare two database schemas. These are invaluable for ensuring that all the database changes, such as new columns and changed PL/SQL, are promoted from the development environment to the test and production environments.

Figure 4-12. Raw, unformatted PL/SQL code

Figure 4-13. PL/SQL automatically formatted by SQL Developer

Security

Security in any computer environment is important. Security is divided into several areas:

• Authentication
• Authorization
• Session-state protection

The sections that follow go into each of these areas in a bit more detail.

Authentication

Authentication controls who is allowed to log on to an APEX application. APEX supports a number of authentication schemes:

• Application Express accounts
• Custom authentication schemes
• Database accounts
• HTTP header variables
• LDAP directory
• No authentication (using Database Access Descriptor [DAD])
• Open door credentials
• Oracle Application Server SSO

As you can see from this list, authentication schemes span a wide range from no authentication for purely public web sites to sites that are secured by integrating with an existing companywide operating system logon infrastructure using LDAP or Oracle SSO.

Authorization

Authorization controls a user’s access to various parts of an application after the user logs on to your application. APEX is very granular in this respect: you can hide or disable large things like modules and pages as well as detailed artifacts like individual data items, buttons, and report columns. Authorization involves assigning roles to user groups and then writing a suite of PL/SQL boolean functions that are called from the APEX object you want to control.

Session-State Protection

Session-state protection is important for defending your APEX application from unauthorized hackers. Three common security vectors are

• URL tampering
• Cross-site scripting
• SQL injection

URL tampering occurs when hackers edit a browser’s URL directly or edit hidden items on a web page. In APEX 3.2, the concept of session-state protection was introduced. Session-state protection adds a checksum to the URL that prevents hackers from manually changing a page number in a URL from an authorized page to an unauthorized page. This concept has become more granular in APEX 4.x (see Figure 4-14) by allowing more control options.

Figure 4-14. Enabling granular session-state protection

Cross-site scripting is done by injecting JavaScript into a web page. This can be done by entering malicious code into a comment item and saving it to the database. When the rogue comment data is returned from the database to the browser, the browser happily executes the JavaScript. The wizards in APEX 4.x now do a lot to protect programmers from this danger by automatically selecting items that “escape” data that is sent to the browser. For example, setting a report column to “Display as Text (escape special characters, does not save state)” explicitly stops JavaScript code in the column from being executed by the browser. The term escape refers to the process of stripping out JavaScript code from the data that is sent to the browser. It is still possible, however, for programmers to select item types that allow dangerous JavaScript to be inserted into a page.

SQL injection is similar to cross-site scripting. Instead of malicious JavaScript being injected into a web page, malicious SQL is sent to the database and then returns unauthorized data to the browser. In most areas of APEX, this is not a problem because the standard way of building SQL statements in APEX uses bind variables. Problems with SQL injection can arise when programmers build dynamic SQL statements when using the SQL report type “SQL Query (PL/SQL function body returning SQL Query).”

A detailed discussion of web security in an APEX environment is out of scope for this book; however, the book Expert Oracle Application Express (Apress, 2011) contains an excellent chapter on these topics and shows, in detail, how to prevent the problems in an APEX web environment.

Core Debugging Tools

Developers are not perfect. Sometimes you make mistakes, and then you have to spend time fixing them. These core debugging tools help you to fix mistakes:

• APEX debugging
• APEX Advisor
• Firefox Developer Toolbar add-in

The APEX Application Builder contains a built-in debugger that is useful for finding errors and performance issues in an APEX application. The APEX debugger is probably the first place you will look when you experience bad behavior in an APEX application. APEX debugging in APEX version 4.x must be explicitly turned on for each application (see Figure 4-15). Once debugging is turned on for your application, you can toggle it on for any individual page that appears to have a problem (see Figure 4-16). After you run a page with Debug toggled on, you can click the View Debug button to see the detailed execution plan for the page (see Figure 4-17), which lists every statement that is executed by the APEX engine as it renders your page. The time taken by each step is measured so you can easily see which statements are causing performance problems.

Figure 4-15. Turn debugging on in APEX Application Builder.

Figure 4-16. The Debug toggle is on each page.

Figure 4-17. Debug shows precise times for loading a page.

APEX debugging exposes its API through the PL/SQL package APEX_DEBUG_MESSAGE. This package allows you to add log messages to PL/SQL code in APEX anonymous blocks and in any code that is called from within the context of an APEX application. The API is simple and effective. It consists of the following routines:

• ENABLE_DEBUG_MESSAGES
• DISABLE_DEBUG_MESSAGES
• REMOVE_SESSION_MESSAGES
• REMOVE_DEBUG_BY_APP
• REMOVE_DEBUG_BY_AGE
• REMOVE_DEBUG_BY_VIEW
• LOG_MESSAGE
• LOG_LONG_MESSAGE
• LOG_PAGE_SESSION_STATE

Expert Oracle Application Express fully documents this API and contains good pointers regarding its effective usage.

The APEX Advisor is a valuable tool for

• Finding bugs
• Areas where quality can be improved
• Areas where performance can be improved

Figure 4-18 shows the rich set of options available in the APEX Advisor. Hover over each check-box label to see a tool tip that give a little more information about the option. Figure 4-19 is an example of one line item from the APEX Advisor that gives you a flavor of the Advisor’s style.

The Firefox Developer Toolbar add-in is a great tool for designing and debugging your web page layout. Figure 4-20 illustrates a simple web page whose table cells have been highlighted by the Developer Toolbar. You can imagine how helpful this tool can be when dealing with web layout issues. The Developer Toolbar does a lot more; it helps organize cookies, CSS, web forms, images, page outline, and many other page issues.

Figure 4-18. APEX Advisor options

Figure 4-19. APEX Advisor sample result.

Figure 4-20. Firefox Developer Toolbar add-in table cell layout example

Extended Technologies

Table 4-3 summarizes some of the common extended technologies used in the APEX environment. The extended technologies and the suggested tools are used to add functionality that is not native to APEX. This list is not exhaustive; however, it gives you a good starting point for evaluating what tools and skills you need in order to extend and enhance the APEX framework.

Table 4-3. APEX Extended Technologies and Tools

Publishing

Out of the box, APEX provides primitive printing functionality. Reports can easily be exported to comma-separated value (CSV) files that are printed using Microsoft Excel. Professional quality and well-formatted reports can only be produced by using one of the following external report engines:

• Oracle BI Publisher
• OC4J with Apache FOP
• XSL-FO processing engines
• PL/PDF

Oracle BI Publisher fits extremely well with APEX. One of its attractive features is the ability to format the report templates with an intuitive and easy-to-use plug-in for Microsoft Word. Unfortunately, it comes with a high license cost. The other options have inexpensive capital cost but require more coding effort.

APEX API

APEX has a rich PL/SQL and JavaScript API. These are used when the default Application Builder cannot meet a user requirement declaratively. For example, sometimes users want to see a multiselect list built using check boxes. In order to do this, you must loop through the lookup table and create a check box for each row in the lookup table. The APEX_ITEM package is used for this type of solution. The following is the list of APIs available in APEX 4.1. The names give you a hint about the kinds of procedures and functions that are available. The APEX home page documentation contains their detailed definitions:

• APEX_APPLICATION
• APEX_APPLICATION_INSTALL
• APEX_COLLECTION
• APEX_CSS
• APEX_CUSTOM_AUTH
• APEX_DEBUG_MESSAGE
• APEX_ERROR
• APEX_INSTANCE_ADMIN
• APEX_ITEM
• APEX_JAVASCRIPT
• APEX_LDAP
• APEX_MAIL
• APEX_PLSQL_JOB
• APEX_PLUGIN
• APEX_PLUGIN_UTIL
• APEX_UI_DEFAULT_UPDATE
• APEX_UTIL
• APEX_WEB_SERVICE
• JavaScript APIs

Themes and Templates

APEX 4.1 comes with 23 themes. These themes are used to build good-quality business applications and are largely interchangeable (see Figures 4-21 and 4-22). However, there are situations where the out-of-the-box themes must be replaced by a custom theme. Some companies have critical branding targets that require all public-facing venues, including web pages, to meet precisely defined graphic standards.

Figure 4-21. Employee report rendered by theme 10 - Sand

Figure 4-22. Employee report rendered by theme 23 - Crimson

In this case, the APEX development team must create a custom theme. Building a custom theme requires knowledge of

• APEX theme/template framework
• HTML
• CSS
• FTP tool (FileZilla)

Building an APEX theme and template framework is not yet a purely declarative process. You must dig into the existing templates and study how they are assembled. A good working knowledge of standards-based HTML and CSS is required for this work. You can test your HTML and CSS to make sure they conform to the latest standards by running your pages through the tests found at these sites:

• http://validator.w3.org/
• http://jigsaw.w3.org/css-validator/

APEX environments that use the Embedded PL/SQL Gateway store their CSS files in the database, not in the file system. You can access and maintain the CSS files by using a File Transfer Protocol (FTP) tool like FileZilla. Some web authoring tools like Adobe Dreamweaver enable you to edit the CSS files directly without having to go through the FTP cycle of download, edit, and upload every time a CSS change is required.

JavaScript

Prior to APEX 4.0, JavaScript was required if you needed to build an interface that competed with the rich user interfaces that are traditionally associated with compiled client/server applications using tools like Java, .NET, C++, and so on. With the introduction of Dynamic Actions in APEX 4.0, the requirement for JavaScript and AJAX has dropped dramatically. Dynamic Actions allow you to build JavaScript functionality declaratively, which eliminates a lot of hand-coded JavaScript and the related debugging headaches.

If you still feel the need to employ JavaScript, a number of JavaScript libraries contain many interface widgets that supply rich interface functionality. You must study these libraries carefully before using them in an APEX context. You also need to understand the web’s Document Object Model in order to manipulate the page objects efficiently and effectively. A working knowledge of AJAX is also handy so you can do partial page refreshing to avoid full-page refreshes. Full-page refreshes can be painfully slow when you load your pages with the rich JavaScript UI widgets.

Public APIs

There are popular and well-documented public web APIs that can be used to add polish and pizzazz to your APEX web pages. Google Maps and Bing are good examples (see Figure 4-23). Integrating Google Maps into APEX applications is illustrated in a number of white papers presented at various Oracle conferences like Kscope, the annual conference hosted by the Oracle Development Tools User Group (ODTUG).

Figure 4-23. A public APEX web site that uses the Bing API

APEX Multilingual Applications

Both APEX and Oracle explicitly support multilingual applications. This is often a requirement in our multicultural and interconnected world.

The APEX application builder itself is available in a number of primary languages that are used in most of the developed world; an exact count is difficult as new ones are being added continually. English is the default language installed in a fresh instance of APEX. Scripts must be run after the initial English installation to translate the application builder into one of the other primary languages.

You build a multilingual application by first developing the application in one of the primary languages. The primary application is then translated to one or more of the 132 secondary languages supported by Oracle. Changes to the application are always done in the primary-language copy and then published to the secondary-language clones.

Publishing or translating an application from its primary language to a child language involves a number of steps. To get started, go to the Globalization menu in your primary application’s Shared Components area (see Figure 4-24). When you select the Translate Application menu option, you are taken to the page that launches the utilities you need to translate your application (see Figure 4-25). Online help is available on this page. If you need a more detailed discussion of the topic, have a look at the book Expert Oracle Application Express, which contains a full chapter on this topic.

Figure 4-24. Globalization in Shared Components is the translation starting point.

Figure 4-25. The How to Translate page steps you through the translation process.

Advanced Debugging Tools

Complex APEX applications need enhanced debugging tools that work in conjunction with the core debugging tools. The suggested toolset is

• Firebug
• SQL Developer (PL/SQL debugging)
• Logger (instrumentation)

Firebug is an add-in for Firefox. It enables developers to test and debug their JavaScript, HTML, and CSS work. The tool enables you to see the structure of your web pages side by side with the HTML and CSS code that generates the page. Firebug also enables you to single-step through your JavaScript code and inspect the values of the code’s variables. It is a very powerful tool, indeed.

To launch Firebug in your Firefox browser, click the small icon in the upper-right corner (see Figure 4-26). This opens a world of debugging tools and options in your browser. Neatly formatted HTML and the related CSS are displayed immediately below your APEX application development area; this demonstrates the seriously practical power of Firebug (see Figure 4-27). You need to set aside a significant amount of time to learn how to use this tool effectively; however, it will be time well spent.

Figure 4-26. The Firebug icon launches Firebug in the Firefox browser.

Figure 4-27. Firebug in action

SQL Developer contains an easy-to-use PL/SQL debugger. To use this facility, you compile your PL/SQL package for debug and then click the bug icon (see Figure 4-28) to bring up the dialog that enables you to run a procedure or function in your package (see Figure 4-29). The PL/SQL block code is automatically generated by SQL Developer; all you need to do is change the values of the routine’s input parameters. The PL/SQL block code can be saved and retrieved later, which is handy when many input parameters must be tested in multiple combinations.

Figure 4-28. SQL Developer PL/SQL development page

Figure 4-29. SQL Developer PL/SQL debugger launch page

Logger is a free utility that comes with excellent references. It is used to instrument your PL/SQL code and to log runtime errors. The code and its documentation can be downloaded from

http://tylermuth.wordpress.com/2009/11/03/logger-a-plsql-logging-and-debugging-utility/

Summary

APEX can be looked at as both a stand-alone web development tool and as a framework. APEX developers can produce good-quality applications by using nothing but APEX and a rudimentary knowledge of SQL. However, when you want to adhere to Agile’s principle of “continuous attention to technical excellence and good design,” you’ll quickly find yourself adding core APEX technologies to your APEX toolbox. Adding polish and pizzazz requires going outside the APEX world to include things like JavaScript widgets and Google Maps.

Moving away from the basic APEX Application Builder requires more tools and skills. The larger number of tools and skills can be effectively managed within the values and principles of Agile software development; however, the governance effort must move from a lighter-weight model to a slightly heavier approach.