In this series of tutorials we have looked at using the apex_application API and learned how to create dynamic branches to return to previous pages. In Part 2 we created a blank About page, which we will now build on using different substitution strings to add extra fields and information.

It is assumed that you have a workspace with the Sample Application installed, as we will be building on this application, and that you have worked through Exercise 2, as we will be adding to the page we created then. [more]

Part one of this tutorial demonstrated the use of the apex_application API. This second part will build on this to look at other substitution strings that are available and how they can be used. The exercise below will create a simple “About” page that can be used for any APEX application. It is assumed that you have a workspace with the Sample Application installed as we will be building upon this application and it’s data structure. [more]

One of the most common pieces of functionality we use as Oracle Forms developers is substitution strings. Everything from user and sysdate in triggers to system variables such as :system.current_item in Forms. Substitution strings are also used in APEX and this tutorial aims to show how these substitution strings can be referenced and used. It is assumed that you have a workspace with the Sample Application installed, as we will be building upon this application and its data structure. [more]

Prior to training, we’ve found it really useful that developers install Oracle APEX and Oracle XE locally. Not only does this give them a safe environment in which to experiment, but it gives them an understanding of what Oracle APEX actually is. They can use this knowledge to help support our customer installations and in investigation of any setup or installation issues that we have.

The following step-by-step instructions have been followed successfully by many developers now and we’ve got the installation time down to well under two hours, including configuration. [more]

As we’ve recently started work on our first big APEX development, it was my task to train up a group of our Oracle Forms developers. Training took the form of a two day course, where I provided an overview of what APEX is, explained why we’ve chosen to use it and then provided practical training to allow them to start development. Obviously there have been a few questions along the way, but really the developers have been able to develop using APEX since the course finished. [more]

Working with a large database we have over 1000 database triggers and we have a lot of business logic and functionality built into database objects. Included in these objects is validation which displays error messages we have defined. The validation generates a code which is then picked up in Oracle Forms and converted to a user friendly message which is displayed to the user. One of the main reasons for having this validation in the database rather than the front-end is because we have a number of forms that access the same tables, so instead of adding the validation to each of these forms we add it to the trigger instead.

Now that we’re using APEX, the standard error page template that APEX uses isn’t sufficient. It means nothing to the end user to see ‘ORA-20101: SSL-12345 ORA-06512: at “OWNER.COST_BTRG”, line 1393″‘. So how can we use APEX to convert this into more user-friendly information that users are used to seeing? [more]

Everyone sees things differently. Some people don’t like brown, others don’t like red, some people are colour blind, others are partially sighted. How can you cater for everyone’s needs and tastes? I don’t think you can, but we’re going to try our best by providing three choices of CSS file and allowing the user to choose which one they prefer. By using a little bit of Javascript we can even change the CSS file used simply by reloading the page. [more]

As a large company we already have a number of software products available using different technologies, like Oracle Forms. Because of this we have a number of teams, like the Technical Authoring Team, who are dedicated to providing a service for all the products. The Technical Authoring Team provide help pages, user guides and release notes for all products. The Configuration Management Team provide installation guides, packaged software and upgrade support for all products. Now that we’re starting to use APEX we don’t want an additional overhead of having to provide a different service specifically for this product. However, as a web application, users want to be able to access things like Help documentation easily and would want to be able to add to this documentation. [more]

I haven’t had much use for Trees in APEX in the past. However, when trying to decide on a navigational aid in our new development project I’ve turned to Trees as a possible solution. We’ve taken the decision to use one of the built in themes and customise it for our purpose. Once we had decided on the theme it was quickly decided that the breadcrumb region took up too much space and wasn’t really fit for purpose so wouldn’t be used. We needed a solution so that users could quickly navigate to different areas of the application and also see how they got to the page they’re on and where they are within the application. The Tree style seemed like the ideal solution but a basic Tree would not do what we wanted, so some thought was required. [more]

I’ve been working with APEX for the past 2 years on internal development, but as a company we’re only just starting to develop commercial applications.

Traditionally our development has been done using Oracle Forms or more recently using a multi-tiered JBOSS environment (which seems too complex and convoluted to be practical). In preparation for the new development projects using APEX I held a 2 day internal training course. This was extremely well received and everyone involved was incredibly positive and excited. No one on the course had used APEX before so we were starting from scratch, but by the end everyone had created a new application, had used substitution variables, the APEX APIs and PL/SQL to generate web pages using the HTP package.

Using Oracle Forms we are used to using a ‘bodge’ or having to ‘fudge’ code to get the results we wanted. [more]