APEX is so easy to get started with, that many developers just start an application, as a prototype, and gradually this application is adapted by the end users, and “glides” into a production state. Thinking about at few simple guidelines during the development phase, can really help make the maintenance/enhancement phase a lot easier.

I have divided the best practices into 3 areas: Installation, Pre-development and Development. Many of the practices are learnings from APEX books, seminars, and experience from many APEX projects.

Installation

The APEX installation is fairly simple, however here are a few tips:

• Install APEX in its own tablespace (I always install APEX objects in a tablespace called “APEX”). This way the APEX objects can be backup up separately if needed, and it is easier to control the growth.
• The same goes for tablespaces for your APEX projects. I create 1 tablespace per APEX workspace (before reating the workspace). The database schema for the workspace should be created like “CREATE USER APP1 DEFAULT TABLESPACE APP1″. After creating the database user, create the workspace (based on the existing user).
• Concerning choice of web server, the new APEX listener is really great for serving the dynamic APEX content from the database. However running the listener in “stand alone” mode should only be used when developing -not in production. I have seen that rendering static files in the standalone mode is not optimal.
• Concerning your own (custom) static files, it is best to keep these in a separate directory on the server. Remember that when APEX is updated, the APEX image catalog will be replaced with files from the new installation.

Pre-Development

When starting APEX development, the following advice is good to remember:

• Create seperate user accounts for the developers. At some point it could be necessary to see who changed what.
• Setup “User Interface Defaults”. This setup is performed on table/column level, and is only necessary to do once. Setup as much as you can : Prompts, Help text, lengths, item types etc. These values are used when creating new components (regions, fields..) using the APEX wizards.
• Determine the strategy for re-use. If the application components (List of values, templates…) can be re-used in other applications, you should consider created a “master” application containing re-usable components. The new application should then “subscribe” to the components in the master application.
• Determine which theme to use. If all applications used in the company should have the same look and feel, consider setting up a company specific theme. Select one of the standard APEX themes, and modify this to your company needs.
• Design the data and process model. The SQL Developer tool from Oracle includes the “Datamodeller” which can be a great help in creating these models. For larger applications, consider integrating the model with the APEX application. This can be achieved by exporting the model from SQL developer (into a “Reporting schema”).
• Decide the security model for your application. A number of Authorization schemes should be created, and can then be used when creating new tabs, pages and other APEX components.
• Decide the strategy for deployment between environments (dev/test/prod). Basically the APEX application (and database objects) can be deployed manually (using the standard DDL files, program files and APEX .sql file), or “packed” into a single .sql using “Supporting Objects”. The build in supporting objects is most useful, when the same application should be deployed on multiple environments (ex. when selling the application to multiple customers). If manuel deployment is chosen, consider creating a install.sql file which created database objects, and deploys PL/SQL program modules etc.
• Set up version control. This is always a point asked by new users, since APEX version control differs from many other development environments. Know this: APEX has build in tracking (and reports) to show which developer changed what at wha time. The standard file artifact from APEX is a single .sql file containing the complete application. This singe file can be saved in a standard version control system (CVS, SVN…) however is can not really be used to show the application changes (its just a bunch of PL/SQL calls which builds the application). Consider using the APEXReportSplitter if there is a need to store and track  each APEX component in a file based versioning system.

Development

During the development phase, these tips can make life easier:

• Place all PL/SQL logic in database packages. This way it is much easier to maintain the code, and use IDE’s which are best at coding in PL/SQL. Another benefit is that the stored PL/SQL program units can be re-used by other programs. It means keeping the presentation logic seperate from controlling and domain logic (MVC pattern). Note that SQL Developer has a tool for migrating PL/SQL code in APEX to packages.
• Plugins can be downloaded from several sites, and used in the APEX application. This is a great way to improve the look and feel of the application without spending a lot of development time. The sites are APEX-plugin.com and the Oracle plugin repository.
• When find yourself creating the same components several times, consider building your own plugins. Company wide plugins are highly efficient for keeping the same look and feel, and then the code has en single place of maintenance. When creating these enterprise plugins, the PL/SQL code behing the plugin can be placed in database packages (in a common database schema). So even if the plugin instance is loaded into many applications, the code behind the plugin can be maintained in one place (per database).
• Page Zero: Another way to re-use with the application, is to place components on Page Zero. You can use the “Condition” to specify which page(s) the component should be displayed on.
• Use Dynamic Actions instead of home made javascript. Dynamic Actions are declarative, which means other programmers can see that the logic exists on the page (instead of having this hidden as custom javascript on the page).
• If you do resort to custom Javascript, consider using JQuery, so there is a better change of cross browser compatibility.
• One of the greatest advantages in APEX is the Interactive Reports (IR). Use this whenever you can, because it works great for the in-experienced user, and at the same time gives great reporting capability to the more advanced end users. However take care concerning the query behind the report. Especially function calls in the column list can really drain the CPU.
• Aliases: Use aliases for applications and for the pages which are linked directly by users. The application and page id can change, so a link containing aliases are better.

More on best practices (in Danish) here.

Happy APEX Developing, and let me know what should be added to the list

Martin B. Nielsen

Derfor søger vi løbende nye medarbejdere/freelance partnere, med følgende skills:

• Oracle Application Express (APEX)
• SQL
• PL/SQL
• HTML, CSS, Javascript, jQuery

Hvis du er interesseret i at arbejde med os, send venligst dit CV til Martin Nielsen, eller kontakt os på telefon 40 98 96 37.

Med udsigt over Holbæk Fjord, samt til Orø og Hørby Færgekro med lystbådehavn – har MBNDATA  fået nye og større lokaler at boltre sig i. MBNDATA’s Salgs- og Marketingafdeling vil herfra yde vore kunder og samarbejdspartnere den perfekte service i nye omgivelser.

Har du/ I spørgsmål der vedrører jeres eksisterende it-løsning, eller står I og skal investere i ny – så kontakt endelig vores salgs- og martingansvarlig, Peter Klug på mobil +45 2623 2676, eller mail: peter@mbndata.dk . Vi tilbyder, ganske uforpligtende, at lave en mindre it-løsning – baseret på interne data. Fremsend dette og vi udarbejder Jeres nye og fremtidssikrede it-løsning.

Vores nye er adresse er:
MBNDATA
Østerled 28A
4300 Holbæk

Vi glæder os til at høre fra jer!

Hilsen

MBNDATA

Agendagen er:

15:00 – 15:15 : Velkomst
15:15 – 16:00 : APEX/Data Modeler Integration – Et eksempel på Architectural Software Development,v / Marc de Oliveira, Simplify Systems
16:00 – 16:30 : Kaffe + networking
16:30 – 17:15 : Brug af Plugins og Dynamic actions i APEX 4.0 v/ Martin Nielsen, MBNDATA

Dette er det første møde i gruppen, men der planlægges at afholde disse møde ca. hver 3. måned. Jeg håber meget at vi kan få samlet en stor interesse for dette område, da det giver en god mulighed for at holde sig ajour med nyeste funktioner, teknikker etc.

Jeg har desuden forespurgt Oracle om vi kan få besøg af et medlem af APEX teamet til at fortælle lidt om nye features i APEX Version 4.1.

Løsningen ligger i størrelsesordenen 600-700 Oracle Application Express (APEX) skærmbilleder, samt en del rapporter og PL/SQL program enheder. Det nye system afløser et ældre systemet som er baseret op Filemaker.

Et projekt i denne størrelsesorden stiller store krav til værktøjets fleksibilitet, og muligheder for genbrug samt autogenerering af skærmbilleder, men APEX har vist sig at leve fuld op til forventningerne. Især har følgende teknologier været en stor hjælp:

• Tæt integration til data og processmodel (igennem SQL Developer Datamodeller – reporting scheme). Menuer samt brødkrumme-spor dannes automatisk ud fra process modellen.
• Tilpassede Templates
• Plugins (standard og skræddersyede)
• User Interface Defaults
• Jasper Reports (PDF rapporter)
• Intelligente context regioner

For ydereligere oplysning om projektet henvises til Kundecase 1 – Danish Institure for study abroad.

So i created a public “AMI” created in the EBS storage. This means it can be started with all instance types (machine sizes),  even the new “micro” machine, which costs $0.025 per hour (about 18 $ per month). The machine is dedicated to running Oracle APEX in a no-license cost environment.

The machine includes:

• Oracle XE (10.2.0.1)
• APEX (4.0.1)
• APEX Listener (1.0.2)
• Tomcat6
• Apache2 (mod_jk for APEX listener integration)
• APEX FOP (Printing PDF in intercative reports)
• Mail
• Jasper Reports (APEX integration by Ditmar Aust)

In other words all the stuff you need to develop and run APEX applications in the cloud.

Installation

Well, all you need is an Amazon cloud account. Once you have this, log in to the Management console, and create a new machine from the AMI called :

• id : ami-8c7b4ef8
• name : mbndata-oracle-apex-community-ubuntu-10-04-LTS

Note: The AMI is currently only available in the EU West Region.

Creating a new instance by right-clicking the AMI like this, and choosing “launch instance”

As soon as the instance is running, you can access the machine (SSH for remote logon), and http for APEX access. The url for APEX is : http://<Public DNS name>/apex.

Ex. : http://ec2-46-51-190-111.eu-west-1.compute.amazonaws.com/apex

You can use “Elastic IP” to give the server a static IP adress which you can then link to your preferred domain.

Please note: The password to any administrative APEX or unix user is “manager” (so please change this right after creating the machine). The only APEX workspace which is created, is the DEMO workspace (log on with demo/demo). This workspace contains sample application (database and websheet), plus the demo application for iReport integration (by Ditmar Aust). For iReport testing, use the port 8090 instead of 8080.

Thats it.

Please note that the machine comes “as is”, simply as a help to the community. It has NOT been through extensive testing, so before using this for mission critical applications, please handle issues such as backup, security etc.

Enjoy

Martin B. Nielsen

Since APEX doesnt include the jquery ui for tabs I decided to create a tab plugin. This particular plugin is designed to include other apex pages in iframes as the tabs.

When you have installed the plugin you can define 3 attributes:

• Region ID’s
• Region Names
• Sources

You must set all 3 attributes.

Region ID’s is the id of the tab, but also the name of the pages that should be shown. Every APEX page can have its own PAGE_ALIAS, which can be referenced in the url. That is what should be put in here. All the id’s/pages must be seperated with :

Region Names is the labels of the tabs. These are also seperated by : There must offcause be the same amount of labels as pages.

Sources is used if you want to send some variables to the page that should be shown. F.x. if you want to send an id from page 8 to page 12 you would write: P8_ID:&P12_ID.

The Sources must be seperated by |.

The plugin can be downloaded here.