Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

(Sign In/Register for Account | Subscribe)

secure search Technology Network

PRODUCTS GETTING STARTED DOW NLOADS DOCUMENTATION FORUMS ARTICLES SAMPLE CODE TUTORIALS
Database
Printer View E-mail this page Bookmark
Middleware
Developer Tools
Enterprise Management
Applications Technology
Products A-Z
Return to Oracle APEX Home
TECHNOLOGIES
BI & Data Warehousing Oracle Application Express
Embedded
Java
Linux
.NET Oracle Application Express Developer Competition 2009
PHP
Security The Oracle Technology Network (OTN) is conducting a competition to promote the dev elopment of new Oracle Application
Technologies A-Z Express (APEX) applications by Oracle dev elopers.
To f ind out more about Oracle Application Express, please v isit the APEX Homepage on OTN.
ARCHITECTURE
Enterprise Architecture IMPORTANT UPDATE: The deadline f or submissions has been extended to 17:00 Eastern US Day light Time (EDT = GMT -
Enterprise 2.0 5:00 hours) Friday , 4 September, 2009
Grid
Below are important details f or the APEX Dev eloper Competition including the ability to
Service-Oriented Architecture
register.
Virtualization

COMMUNITY Entry Rules and Eligibility

Application Dev elopment Guidelines
Join OTN
Criteria f or Judging Submissions
Oracle ACEs Prizes / Awards
Oracle Mix Registration
Oracle Wiki
Blogs
Podcasts top
Entry Rules and Eligibility
Events
Newsletters All of these rules must be met in order f or y our application to be accepted:
Oracle Magazine Entry is open to any members of the Oracle Technology Network (OTN), except f or employ ees of Oracle and its
Oracle Books subsidiaries and the judge's companies.
Certification Y ou must be registered on the Oracle Technology Network (OTN) in order to enter the competition. (Register here)
User Groups Y ou can only submit one APEX application.
Partner White Papers Oracle Application Express application criteria -
Must be written in Oracle Application Express 3.2.x.
Be prov ided as a single Packaged Application including necessary supporting objects.
The primary language must be English, including supporting documentation. Optionally , y ou may also
SELECT COUNTRY include other translated language v ersions of the application.
Can incorporate third-party libraries (such as jQuery ) prov iding the third-party licensing agreement(s) are
specif ied in the read-me f ile prov ided with the application.
Can include ref erences to "public" Web Serv ices prov iding the third-party licensing agreement(s) are
specif ied in the read-me f ile prov ided with the application.
May be designed f or deploy ment on either the Internet or Intranets or both.
Submissions must be entered into the APEX Competition Application by 17:00 Eastern US Day light Time (EDT =
GMT - 5:00 hours) on 4 September, 2009.
{APEX Competition Application av ailable af ter accepting the APEX Competition Legal Agreement and registering}
Submissions are f inal, and late or duplicate submissions will not be accepted, unless additional submissions are
requested by Oracle.
The judges decision is f inal.

top
Application Development Guidelines
The f ollowing is adapted f rom the guidelines dev eloped by the APEX Dev elopment Team to build the Packaged
Applications av ailable f or download f rom http://otn.oracle.com/apex.

1 - Ov erv iew
2 - Database Design Considerations
2.1 - Object Naming
2.2 - Constraints
2.3 - Triggers
2.4 - Pl/Sql
2.5 - Other
3 - Application Dev elopment Guidelines
3.1 - Naming
3.2 - Report Formatting
3.3 - Forms
3.4 - Other
4 - Packaging Y our Application
4.1 - Messages
4.2 - Prerequisites
4.3 - Substitutions

1 of 6 10/14/2009 10:37 AM
Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

4.4 - Build Options

4.5 - Validations
4.6 - Scripts
4.7 - Deinstall
4.8 - Other

Application Guidelines
1 - Overview
Oracle Application Express prov ides a hosted, multi-tenant, declarativ e env ironment that simplif ies the task of dev eloping
data driv en web-applications. It also greatly reduces the time taken to deliv er an application f rom inception to deploy ment.
One of the greatest adv antages of using Oracle Application Express is the ability to lev erage the scalability , reliability , and
security of the Oracle Database.

This document prov ides general guidelines to users dev eloping applications using Oracle Application Express. Content
included is based upon y ears of collectiv e experience of the Oracle Application Express Dev elopment team. Adherence to
these guidelines will result in consistent applications that are easier to understand and maintain.

Application Guidelines
2 - Database Design Considerations

Application Guidelines
2.1 - Object Naming
Database objects f or an Application should be pref ixed with an appropriate "identifier". For instance, each object
belonging to the application "Content Management" could be pref ixed with "CM_". This groups all the objects f or a
particular application together and helps to av oid contention f or object names.
Primary Key Constraints should be named <TABLE_NAME>_PK.
Unique Key Constraints should be named <TABLE_NAME>_UK.
Foreign Key Constraints should be named <BASE_TABLE_NAME>_<REFERENCED_TABLE_NAME>_FK.
Check Constraints should be named <BASE_TABLE_NAME>_<COLUMN_BEING_CONSTRAINED>_CC.
Triggers should be named <BASE_TABLE_NAME>_BI, <BASE_TABLE_NAME>_BU, or <BASE_TABLE_NAME>_BIU
(where BI indicates Bef ore Insert, BU indicated Bef ore Update and BIU indicated Bef ore Insert or Update). Other
ty pes of triggers should be similarly named.

Application Guidelines
2.2 - Constraints
Each table should hav e a primary key constraint enabled.
Applications are easier to generate and data is easier to maintain if y ou use sy stem generated primary key s. That
said, each table that has a sy stem-generated primary key should also hav e a unique key implemented (with both a
unique constraint and mandatory column). This key is simply the 'real' primary key of the table - a column or
combination of columns that makes each record unique.
Whenev er y ou hav e a column that ref erences v alues f rom another table, y ou should hav e a Foreign Key
implemented. This enf orces that relationship at the database lev el and includes that in the def inition of the table.
All Foreign Key columns should be indexed. These are the columns that are ty pically used in joins so including a
non-unique index f or each f oreign key column will increase y our perf ormance.
When def ining Foreign Key s, remember to use 'ON DELETE CASCADE' or 'ON DELETE SET NULL' whenev er
appropriate.
Use Check Constraints wherev er necessary . Ev en when y ou will hav e a List of Values limiting the contents of a
particular column, it is good practice to also implement that in a check constraint. This enf orces that rule at the
database lev el f or and protects y our data when it might be modif ied v ia an interf ace that is lacking y our list of
v alues.
Use Unique Key s f or Look Up tables

ALTER TABLE <TABLE_NAME>

ADD CONSTRAINT <TABLE_NAME>_UK
UNIQUE (<COLUMN_NAME>)

Application Guidelines
2.3 - Triggers
When y ou hav e a sy stem-generated Primary Key , y ou should populate it v ia a trigger. This ensures that the same
v alue will be set if the data is created v ia another interf ace or directly on the table (using something other than y our
application such and the SQL Workshop or SQL Dev eloper).
When y ou do use a trigger to populate a Primary Key column, use the Global Unique Identif ier (GUID), howev er,
check to see if the primary key v alue has already been set with code like that below.

IF INSERTING AND :NEW.ID IS NULL THEN

SELECT TO_NUMBER(SYS_GUID(), ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')
INTO :NEW.ID
FROM DUAL;
END IF;

By wrapping y our set command in this if statement, y ou are allowing data to be loaded into y our application that
already has a primary key v alue. This helps with loading of sample data.
We suggest using the Global Unique Identif ier instead of a sequence. This ensures that primary key columns are
populated uniquely while reducing the number of objects that need to be managed. It also helps to ensure
uniqueness in a multi-node env ironment.

Application Guidelines
2.4 - PL/SQL
PL/SQL procedures and f unctions should alway s be logically grouped into a package whenev er possible. Only in
rare circumstances should stand-alone procedures and f unction be implemented. Using packages has many
adv antages, including modularity , easier application design and maintenance, promotes inf ormation hiding, and can
result in better perf ormance.

2 of 6 10/14/2009 10:37 AM
Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

As with other objects, all packages should be pref ixed with y our application pref ix. The remainder of the name
should be descriptiv e of the purpose of the public methods exposed in the package.
For v ariable naming, all global v ariables should be pref ixed with 'g_' to indicate they are global. All local v ariables
should be pref ixed with 'l_' to indicate they are local. All parameters should be pref ixed with 'p_' to indicate they are
parameters.

Application Guidelines
2.5 - Other
Each table should hav e the f ollowing columns to maintain audit inf ormation:

Column Name Type

CREATED_BY VARCHAR2(255)
CREATED_ON DATE
LAST_UPDATED_BY VARCHAR2(255)
LAST_UPDATED_ON DATE

To ensure that the audit inf ormation is consistently added, ensure that they are populated using Triggers:

IF INSERTING THEN
IF :NEW.ID IS NULL THEN
SELECT TO_NUMBER(SYS_GUID(), ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')
INTO :NEW.ID
FROM DUAL;
END IF;
:NEW.CREATED_ON := SYSDATE;
:NEW.CREATED_BY := nvl(v('APP_USER'),USER);
END IF;

IF UPDATING THEN
:NEW.UPDATED_ON := SYSDATE;
:NEW.UPDATED_BY := nvl(v('APP_USER'),USER);
END IF;

If y ou require f ull history of the updates made, y ou will need to accomplish that with a more robust data model.
To ensure that the Underly ing data model is f lexible to f uture changes or expansion, each table should hav e least 5
redundant or 'Flex' Columns. For instance:

Column Name Type

FLEX_01 VARCHAR2(4000)
FLEX_02 VARCHAR2(4000)
FLEX_03 VARCHAR2(4000)
FLEX_04 VARCHAR2(4000)
FLEX_05 VARCHAR2(4000)

Application Guidelines
3 - Application Development Guidelines

Application Guidelines
3.1 - Naming
Whenev er possible, Menu items, Breadcrumbs, Region Names, and Page Titles should be named consistently . If
y ou access a page by clicking on a Menu Item called "Annual Report", the Page Title, Region Title and breadcrumb
of the page display ed should also be "Annual Report". Y ou might not realize it but the Page Title is display ed as the
main title in y our browser when the page is display ed.
Reports should ideally be named in the plural. They display multiple rows.
Forms should be named in the singular. They display only one row of data at a time. The exception to this is a
Tabular Form.
Labels f or Display only Items should be end with a colon. This helps to separate the label f rom the data. Labels f or
enterable items should only end in a colon if the item ty pe is a radio group.
Av oid hard-coding text in a Template. Instead, v alues should be ref erenced using Substitution Strings or Shortcuts.
These can then be ref erenced as #SHORTCUT_1# in y our template.

Application Guidelines
3.2 - Report Formatting
Numeric v alues should be display ed as Right Justif ied.
Use appropriate f ormat masks on numbers.
Consider changing upper case data to initcaps f or reports. Uppercase text takes up much more horizontal space
and draws more attention f rom a user than it should.
Reports based on table should include the ‘f lex’ columns but should not be display ed. This will make it easier f or a
dev eloper to expose them in the f uture.
Use a consistent Pagination Scheme f or all reports within an Application. Y ou can dev iate f rom this whenev er y ou
hav e a special report that might perf orm poorly using y our giv en scheme. Example of this are when y our selected
pagination is rows x to y of z. If y ou hav e a report that could return a million records, y ou would not want to incur
the perf ormance hit of calculating the z.

Application Guidelines
3.3 - Forms

3 of 6 10/14/2009 10:37 AM
Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

Any items display ed should use the 'Form Field Optional' or 'Form Field Required' label templates prov ided in
Application Express. This v isually indicates to y our users which items are mandatory .
Any page that captures data f or processing should hav e suitable v alidations. Y ou should catch the user at the point
of data entry and check that their data is not null or numeric or meets any other criteria that y ou need. Validations
should alway s be def ined f or any items with a 'Form Field Required' template and all NOT NULL columns in the
underly ing table (unless their v alue is set by a trigger). Remember to use consistent wording when creating y our
error messages.
All items that are display ed should include help text. Y ou may want to wait until the end of dev elopment cy cle to
create y our help so that y ou can keep it consistent across y our application.
One great way to prov ide accurate and consistent help text is to def ine comments on y our table columns and then
def ault User Interf ace Def aults. When this is done, the column comments are read in and will then be used to
def ault help text f or any f orm item created against that column.
Delete actions should include a conf irmation step. This protects users f rom accidentally clicking a delete button and
permanently remov ing data. This can be accomplished by including this jav ascript as the URL target f or y our
delete button:

javascript:confirmDelete('&DELETE_MSG.','DELETE');

DELETE_MSG is an Application Substitution string. Y ou could also hardcode text instead.

It is a good practice to hav e a success or f ailure messages af ter each action (e.g. Sav e, Delete etc.). Ensure that
y our branches are set to 'include process success' so that y our messages will be display ed to the user ev en when
leav ing the page.
Multi-Step processes should store data in the relev ant tables only on completion of the f inal step. For instance,
creating a new user should store the prof ile only once the user conf irms his details and submits.
If y our Application is required to store/maintain temporary data, y ou should use 'Collections' (a f eature of the
Database). This reliev es y ou f rom using y our own temporary table, which y ou would need to maintain.
Forms based on table should include the 'f lex' columns but should not be display ed. This will make it easier f or a
dev eloper to expose them in the f uture.
On each page containing a f orm, include the auditing columns f or the base table but put them in a separate region
with a region template of hide and show. This region should be made conditional and display audit data only if the
Primary Key is Not Null.
The Audit Columns should be made display only , with labels as bold text labels and end each label with a colon.
This helps to dif f erentiate the label f rom the data

Application Guidelines
3.4 - Other
Group all "Maintenance and Administration" Pages under the 'Administration' Tab, with each f unction listed under a
f orm and a report.
If y ou hav e a group of applications that can be glued together to f orm a Suite of Applications, ensure that they
hav e a consistent look and f eel. Begin by selecting a common Theme f or y our applications.
Decode y our data using Lists of Values. This means that if y ou are display ing a column that has a Y indicating
Y es and an N indicating No, create static List of Values and associate with that report column to 'decode' the
v alue. This sav es y ou f rom including a decode or case statement in y our select, allows new v alues to be easily
entered in the f uture and allows f or translation of the data if necessary .
Use a consistent date f ormat throughout y our entire application. Use Application Substitution string named
APP_DATE_FORMAT. Set the def ault f ormat to DD-MON-Y Y Y Y and ref erence it (as &APP_DATE_FORMAT.) f or
each item and report column that display s dates. When y ou package y our application, include this as a substitution
string f or the installation so that it can be changed on install.
Similarly f or Date and time f ormats use the Application Substitution string named APP_DATETIME_FORMAT. Set
the def ault f ormat to DD-MON-Y Y Y Y HH24:MI.
Passing of character data v alues in a URL is strongly discouraged. Nav igation between pages is of ten
accomplished v ia URLs and passing of data v alues to set session sate on the target page. Numeric v alues should
be passed and the corresponding textual v alues retriev ed v ia On-Load Page Processes on the target pages.
For Applications using passwords to authenticate users, alway s store encry pted passwords. Also, these should not
be v isible to the Application Administrator at any time. Only the user should be able to change their password.

Application Guidelines
4 - Packaging Your Application
Supporting Objects utility was introduced with Oracle Application Express 2.2 Release. This allows dev elopers and
administrators to def ine the database objects, images, seed data associated with a particular Application and package
them with the “Application Def inition”. This signif icantly reduces the complexity prev iously associated with installing an
application.

Application Guidelines
4.1 - Messages
There are sev eral messages that can be display ed to y our user. They include Welcome, License, Application
Substitutions, Build Options, Validations, Conf irmation, Post Installation and Deinstallation.
Most messages are simply display ed to the user along choices that they hav e (like Application Substitutions and
Build Options). These ty pes of messages should be used to explain the selections and their ramif ications.
If a License Message is included, the installing user will need to accept the terms bef ore continuing.

Application Guidelines
4.2 - Prerequisites
Free Space: This should alway s be def ined. Y ou can calculate the space that y our initial set of objects (and sample
data) needs by running a Workspace Utilization Report bef ore and af ter y ou install y our application. By determining
the number of by tes that the installation used and div iding that by 1,024 y ou will hav e the amount of Free Space,
in KB, that a user will need to install y our application.
Sy stem Priv ileges: Rev iew the ty pes of objects that y our installation scripts will create and check all those
appropriate. This way if y ou need to create a ty pe but the target user does not hav e that priv ilege, they will get an
elegant error message bef ore any installation script is executed.
Object Names: Y ou should list all the objects that y ou will create. This way those names will be checked f or bef ore
the installation script is executed. Y ou want to protect y our user f rom installing y our application that has a

4 of 6 10/14/2009 10:37 AM
Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

PROJECTS table into a schema that already has a PROJECTS table. Although they would see an installation error,
if they deinstalled the application, y ou could accidentally drop their preexisting table. This Object Name check
protects against that.

Application Guidelines
4.3 - Substitutions
If y our application contains Substitution Strings at the application-lev el, y ou can expose those here f or the installing
user to change. Examples of this would be if y ou hav e a substitution string used f or the product name. Y ou could
allow the installing user to prov ide a new name.

Application Guidelines
4.4 - Build Options
If y our application contains Build Options, y ou can expose those here f or the installing user to set on or of f . Y ou
might hav e some optional f unctionality that they do not want and this both lets them know and also mitigates the
need f or them to go to build options af ter installation to turn one of f . If y ou include these, remember to def ine a
message that explains them.

Application Guidelines
4.5 - Validations
Validations are similar to prerequisites but can be any thing. Y ou may need to check that a certain database option
is installed or v erif y that the database is 9iR2 or greater. A v alidation is where y ou would do that.

Application Guidelines
4.6 - Scripts
Be caref ul with the sequence of y our scripts (e.g. create tables bef ore triggers) and the sequence of objects within
y our scripts. An incorrect sequence of ten results in install f ailures due to database object dependencies. If y ou
hav e many f oreign key s, y ou may need to disable them upon create and then hav e a separate script to enable
them.
Include a script containing comments f or each table and column. This improv es the readability of y our database
def inition and assists others when they need to add a new report to y our application.
If y ou are packaging y our application f or rev iew or demonstration purposes, include sample data. This would be
accomplished with an additional installation script that creates sample data. If y ou do include sample data, consider
making a script av ailable to y our users that will cleanly remov e the sample data.

Application Guidelines
4.7 - Deinstall
The deinstallation script needs to remov e ev ery object that y ou create with y our installation scripts. The end result
of deinstallation should leav e no trace of the installed application.

Application Guidelines
4.8 - Other
If publishing y our packaged application, ensure that the .sql and .zip f ile names are consistent with the Application
name and its v ersion.
Including a readme.txt f ile in the installation .zip f ile is highly recommended. It should contain inf ormation such as:
- A description of the application
- The purpose of the included f iles
How to import and install the application
How to use the script to remov e the sample data
How to deinstall the application
- Any def ault username/password that would be required to run the application.
- Any other inf ormation the installing user might need to know.

top
Criteria for Judging Submissions
Upon submission of a completed application into the APEX Dev eloper Competition application, the APEX Dev elopment
Team will be responsible f or screening the submission to ensure it meets the entry rules and minimum application
guidelines. All eligible applications will then be ev aluated against the judging criteria by the judging panel.

Judging Criteria:

User Interf ace (e.g. ov erall appearance, consistency of presentation).

Usability (e.g. ease of use, nav igation).
Feature Set (e.g. f unctionality prov ided, business applicability ).
Production Quality (e.g. no major bugs).
Documentation (e.g. installation instructions, coding documentation [inline or separate], user guide [optional]).

Judges Panel:

Matt Chiv ers - Oracle

Dimitri Gielis - APEX Evangelists
Justin Kestely n - Oracle
Thomas Marshall - Auburn University
Anton Nielsen - C2 Consulting
John Scott - APEX Evangelists
Scott Spendolini- Sumner Technologies

top
Prizes / Awards

5 of 6 10/14/2009 10:37 AM
Oracle Application Express Developer Competition http://www.oracle.com/technology/products/database/application_express...

The f ollowing prizes will be awarded f or the APEX Dev eloper Competition based on the judges rankings:

First Place - An Unconf erence Session and One complimentary ticket to Oracle Openworld 2009* in San Francisco
October 11 - 15.
Second Place - One complimentary ticket to Oracle Openworld 2009* in San Francisco October 11 - 15.
Third Place - One complimentary ticket to Oracle Openworld 2009* in San Francisco October 11 - 15.
Fourth through Twelfth Place - One copy of the book Pro Oracle Application Express, Apress Publishing, written
by John Scott & Scott Spendolini.

{ * Some conditions apply . Go to http://www.oracle.com/goto/oracleopenworldpasses to learn more.}

The winning application(s) will be f eatured in Oracle Magazine - January / February issue {Feature content to be determined
by Oracle Magazine Editor}.

The highest placed submission f rom residents in the United Kingdom will be giv en a session at UKOUG Technology &
Ebusiness Suite Conf erence 2009 in Birmingham Nov ember 30 - December 2 {UK address must be prov ided during
registration}.

top
Registration
Y ou must accept the APEX Competition Legal Terms, Entry Rules & Eligibility , and Application Dev elopment Guidelines to
register f or this competition.

Accept Legal Agreement | Decline Legal Agreement

APEX Dev eloper Competition Registration Register

E-mail this page

Printer View

About Oracle | | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy

6 of 6 10/14/2009 10:37 AM